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ABSTRACT 

The  main  goal  of  this  thesis  is  to  study  the  perfor¬ 
mance  tradeoffs  between  parallelism  and  increased  con¬ 
currency  control  overhead  during  simultaneous  user  updates 
of  a  database.  During  such  updates,  a  database  management 
system  must  guarantee  that  the  multiple  users  do  rot 
interfere  with  each  other. 

The  potential  advantages  of  parallelism  in  accessing 
a  database  include  the  better  utilization  of  computer 
resources  and  better  response  times  for  users.  Those 
advantages,  however,  may  be  offset  by  the  increased  use  of 
system  resources  to  insure  that  there  is  no  interference 
between,  the  multiple  users.  Simulatior  models  are  used  to 
study  these  two  conflicting  asnects  of  concurrency  control 


for  both  cer.  tra  l  i  zed  and  a  distributed  databases. 

One  of  the  most  i  moor  tart  desigr  decisions  irvolves 
locking  granularity.  Locking  granularity  refers  to  the 
size  and  hence  the  number  of  locks  maintained  by  the  data¬ 
base  management  system.  The  centralized  database  simula¬ 
tion  results  indicated  that  in  many  cases,  in  particular 
if  data  access  is  primarily  sequential,  coarse  granularity 
such  as  file,  relation  or  record  type  locking  is  prefer¬ 
able.  However,  if  all  of  the  updates  are  small  and  ran¬ 
domly  access  the  database,  finer  granularity,  such  as  page 
or  record  locking  becomes  necessary.  If  the  sizes  and 
access  patterns  of  updates  vary  considerably,  the  simula¬ 
tion  results  indicated  that  a  lock  hierarchy  with  dif¬ 
ferent  sized  locks  is  beneficial. 

In  a  distributed  database,  the  data  is  stored  or:  dif¬ 
ferent  computer  sites  connected  through  some  type  of  net¬ 
work.  v  In  such  a  system,  some  of  the  database  activities 
are  local  in  that  they  only  involve  data  at  one  site. 
Other  database  activities  are  distributed  in  that  they 
involve  data  at  several  of  the  computer  sites.  > In  a  dis¬ 
tributed  database,  increased  parallelism  is  possible  dur¬ 
ing  simultaneous  database  activities.  However,  the  cor  - 
currency  control  overhead  may  also  increase.  The  simula¬ 
tions  modeled  a  variety  of  cor  currency  control  algorithms 
to  study  the  additional  tradeoffs  in  a  distributed  data- 
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base . 

In  particular,  primary  site  control  and  decentralized 
control  algorithms  were  simulated.  In  the  primary  site 
cortrol  algorithms,  ore  site  performs  the  concurrency  cor¬ 
trol  functions  for  all  of  the  other  sites.  In  the  decen¬ 
tralized  cortrol  algorithms,  the  concurrency  functions  are 
distributed  to  each  of  the  sites  and  special  provisions 
must  be  used  to  prevent  or  detect  deadlock. 

The  simulation  results  indicated  that  with  a  high 
speed  network  and  mostly  local  database  activities,  either 
concurrency  control  approach  is  acceptable.  As  the  net¬ 
work  becomes  slower,  the  decentralized  control  algorithms 
are  preferable.  If  most  of  the  database  activities  are 
distributed,  however,  the  primary  site  approach  can  take 
advantage  of  its  "globar"  knowledge  to  better  schedule  the 
processing  of  transactions  and  thus  provide  better  perfor¬ 
mance  than  the  decentralized  algorithms. 

These  results  can  provide  insights  into  the  design 
and  implementation  of  the  concurrency  cortrol  mechanisms 
for  a  wide  variety  of  centralized  and  distributed  database 
management  systems. 
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CHAPTER  1 


INTRODUCTION! 

1-  DATABASE  CONCURRENCY  CONTROL 

One  of  the  major  features  of  a  database  management 
system  is  to  allow  multiple  users  access  to  shared  data. 
During  such  multiple  user  access  (ard  update),  the 
"integrity”  of  the  database  must  be  guaranteed.  The 
mechanism  which  guarantees  that  "integrity"  is  commonly 
referred  to  as  the  concurrency  control  subsystem  of  a 
database  management  system. 

Two  conflicting  aspects  of  the  concurrency  control 
mechanism  affect  the  performance  of  a  database  management 
system.  On  the  one  hand,  the  concurrency  control  can 
increase  the  parallelism  allowed  ir.  accessing  the  data¬ 
base.  On  the  other  hand,  the  advantages  of  such  increased 
parallelism  may  be  offset  by  the  amount  of  system 
resources,  or  overhead,  that  are  used  to  irsure  database 
integrity. 

The  main  goal  of  this  thesis  is  to  study  the  perfor¬ 
mance  trade-offs  between  increased  parallelism  ar.d 
increased  concurrency  control  overhead  in  order  to  provide 
insights  for  concurrency  control  implementations  in 
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d a  1. a \)  n s o  m a n  a o m or.  t  s  y  a  t  c m s . 

Jr  the  repair  ier  of  this  chanter,  some  of  the  prob¬ 
lems  ir:  database  cor  currency  eortrol  are  discussed  ar  d  the 
previous  research  results  or  the  per forman ce  evaluatior  of 
corxurr er.cy  eortrol  mechanisms  are  reviewed. 

2.  CONCURRENCY  CONTROL  PROBLEMS 

2 . 1 .  Consistency 

The  database  concurrency  eortrol  subsystem  is  resoor- 
sible  for  the  integrity  ard  cor. si  stercy  of  the  database 
during  multiple  user  updates.  The  following  example 
illustrates  the  type  of  inconsistencies  which  can  arise 
without  concurrency  controls. 

One  user  is  producing  a  summary  report  of  the  total 
salaries,  taxes  and  benefits  that  are  paid  for  a  reiver,  pay 
period.  At  the  same  time  some  other  user  is  updating 
individual  payroll  records  for  the  "next”  payroll. 
Without  some  type  of  concurrency  eortrol,  the  summary 
report  may  include  some  data  from  the  ’’previous”  payroll, 
and  some  from  the  "next”  payroll.  Thus,  the  results  of 
that  report  would  rot  accurately  reflect  either  the  previ¬ 
ous  or  next  payroll  periods. 

Furthermore,  the  report  may  not  accurately  reflect  an 
individual's  payroll  record  for  either  pay  period.  Sup- 
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pose,  for  example,  that  employee  x's  payroll  record  was 
being  updated.  The  summary  report  might  cortair  the  rew 
salary  but  the  old  tax  and  benefit  values. 

The  concept  of  Mdatabase  consistency"  refers  to  the 
permissible  states  of  a  database.  The  states  which  are 
permissible  may  require  certain  r  el  at  ior:  sh  i  ps  between 
various  elements  in  the  database.  For  example,  ore  such 
requirement  may  be  that  a  department  salary  total  must 
equal  the  sum  of  all  of  the  individual  salaries  in  the 
department.  Such  constraints  are  application  dependent 
and  thus  difficult  to  define  for  a  general  database 
management  system . 

In  [ESWA76],  the  concepts  of  transactions  and  serial 
schedules  are  introduced.  A  "  tr  an  sact  ion'1  is  a  set  of 
related  atomic  actions  involving  a  database  which,  if  run 
alone  on  a  database,  preserves  database  consistency.  A 
"schedule"  for  processing  transactions  is  a  sequence  of 
atomic  actions  from  the  tran sac t ion s .  A  "serial  schedule" 
is  ore  in  which  all  the  atomic  actions  from  one  transac¬ 
tion  are  scheduled  first,  followed  by  all  of  the  atomic 
actions  from  a  second  transaction,  etc.  In  other  words, 
the  transactions  are  run  ore  at  a  time  against  the  data¬ 
base  . 

A  transaction  schedule  is  "serializable"  if  the 
effects  of  the  atomic  actions  in  the  scheduled  order  are 
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equivalert  to  rurrirq  the  trarsai-tiors  ir  some  serial 
schedule.  If  etK  h  trar  s:k  tior  preserves  the  cor  sistor^v 
of  the  database,  it  is  clear  that  a  serial  schedule,  ar:d 
thus  a  serializable  schedule,  must  also  preserve  the  cor- 
si store y  of  the  database. 

Two  protocols  for  transaction  behavior  are  defined  ir 
[ESWA7&!  which  are  used  to  insure  the  ser ial izabi 1 ity  of 
any  schedule.  A  transaction  is  said  to  be  11  wel  1-formed" 
if  all  transactions  acquire  a  lock  (read  or  write  [DTJK68, 
C0DR71])  before  touching  (reading  or  writing)  an  object  of 
the  database.  A  transaction  is  said  to  be  "two-phased”  if 
it  acquires  all  of  its  locks  before  releasing  any  locks. 

If  all  transactions  are  two-phased  and  well-formed, 
[FSWA76]  shows  that  any  schedule  of  atomic  actions  that 
does  rot  violate  the  required  lockirg  protocols  is  serial¬ 
izable  and  thus  preserves  the  consistency  of  the  database. 

Some  database  management  systems  support  weaker  forms 
of  consistency  where  the  applications  may  allow  for  cer¬ 
tain  violations  of  the  well-formed  and  two-phased  proto¬ 
cols  [C/RAY76].  It  has  also  beer  shown  (BHRN781  that  seri¬ 
alization  (or  effective  serial izatior )  of  trar.sactior  s  is 
sometimes  unnecessary.  Throughout  this  study,  however,  it 
is  assumed  that  the  concurrency  control  subsystems  require 
that  transactions  are  well-formed  ard  two-phased. 
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?.?.  Deadlock  and  Rollback 

Those  two  protocols  do  provide  solutions  to  some  of  the 
concurrency  control  problems.  However,  other  problems 
which  the  concurrency  control  subsystem  must  still  solve 
include  deadlock  resolution  arid  the  problem  of  cascading 
rollback  of  transactions. 

A  simple  example  can  be  used  to  illustrate  the 
deadlock  problems.  Suppose  one  transaction  locks  and 
writes  object  A  and  another  transaction  similarly  locks 
and  writes  object  B.  Then,  the  first  transaction  requests 
a  lock  on  B  while  the  secord  transaction  requests  a  lock 
on  A.  The  four  conditions  for  deadlock  [C0FF71]  are  met 
since  neither  transaction  can  release  its  existing  locks 
without  violating  the  two-phased  locking  protocol.  Thus, 
a  concurrency  control  scheme  must  solve  deadlock  problems 
by  either  prevention  or  detection  and  resolution. 

If  deadlock  detection  and  resolution  is  used  it  may 
be  necessary  to  roll  back  or  undo  the  effects  of  a  tran¬ 
saction.  Note  that  if  locking  is  not  two-phased,  some 
other  transaction  may  read  the  effects  of  a  transaction 
which  has  beer  rolled  back.  In  this  case  the  other  tran¬ 
saction  must  also  be  rolled  back.  (Otherwise,  the  updates 
of  the  rolled  back  transaction  might  still  appear  ir  other 
parts  of  the  database). 
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This  cord  i  tier  is  called  "cascading"  rollback  and  oar 
be  qen  era  ted  ever  if  two  phased  locking  is  er:  forced.  A 
trap  sac  tier  may  also  be  rolled  back  because  of  a  change  ir 
a  user’s  rnird  ,  or  because  of  a  hardware  problem.  If  that 
transaction  had  released  some  of  its  write  locks,  other 
transactions  min;ht  also  have  to  be  rolled  back.  To 
prevent  this  cascading  rollback,  many  database  systems 
hold  all  locks  until  the  end  of  the  transaction.  Ir.  fact, 
all  of  the  concurrency  cortrol  subsystems  considered  ir. 
this  study  will  require  that  leeks  be  held  until  the  end 
of  a  transaction . 

2.3.  Database  versus  Operating  System  Concur rerc_y 

The  concurrency  control  requirements  for  databases 
are  different  than  the  concurrency  cortrol  requirements 
for  operating  systems.  One  difference  is  that  an  operat¬ 
ing  system  controls  simultaneous  access  to  fixed  objects; 
such  as  line  printers,  tape  drives,  specific  addresses  ir 
core,  etc.  A  database  system,  or:  the  other  hand,  cortrols 
access  to  objects  whose  names  and  addresses  car.  change. 

Another  difference  is  that  more  objects  reed  to  be 
locked  ir*  a  database  management  system.  The  database  may 
cortair  millions  of  objects,  such  as  records,  field 
values,  etc.,  which  have  to  be  locked.  The  number  of  dif¬ 
ferent  objects  that  car  be  locked  ir  an  oneratir^  system 
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is  generally  much  smaller. 

3.  PREVIOUS  PERFORMANCE  R^S[JLTS 

The  results  of  the  above  problems  and  consistency 
requirements  have  resulted  in  a  wide  variety  of  different 
concurrency  control  mechanisms.  The  goal  of  this  thesis, 
however,  is  not  to  develop  new  concurrency  control  algo¬ 
rithms,  but  to  study  the  affects  of  various  concurrency 
control  strategies  on  the  overall  performance  of  the  data¬ 
base  management  system  by  means  of  simulation  models. 
Previous  work  in  this  area  can  be  divided  into  centralized 
databases,  where  the  entire  database  is  maintained  by  one 
computer;  and  distributed  databases,  where  the  database  is 
distributed  across  several  computers  connected  by  some 
type  of  network. 

3 . 1_ •  Centralized  Databases 

In  [NAKA75]  a  simulation  model  is  used  to  study  the 
performance  of  a  database  system.  A  database  system  model 
and  synthetic  user  application  models  were  run  to  estimate 
system  utilizatiors  and  average  response  times.  One 
result  observed  was  that  the  system  bottlenecked  due  to 
the  delays  caused  by  concurrent  updates.  When  the  con¬ 
current  updates  were  administratively  removed  from  the 
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arolicatior  model  (to  oresumabl  v  bo  rur  at  right),  the 
average  respoi  so  time  decreased  hv  a  factor  of  sever:. 
Sirco  rot  all  applications  allow  for  administrative  vor- 
currer.oy  control,  it  is  clear’  that  coreurrerc  v  control 
mechanisms  can  si  gr:  i  f  icar  1 1  y  affect  the  overall  perfor¬ 
mance  of  the  database  management  system. 

Several  other  simulation  studies  have  also  explored 
the  effects  of  concurrency  control  or  database  system  per¬ 
formance.  In  [SPIT76]  the  effect  of  scheduling  the  lock 
requests  and  releases  for  the  System  ?000  database  manage¬ 
ment  system  was  examined.  In  that  study,  the  difference 
between  lockirg  the  database  for  the  entire  period  of  a 
transaction,  as  opposed  to  locking  and  unlocking  the  data¬ 
base  for  each  atomic  update  was  surprisingly  small.  The 
additional  parallelism  possible  with  the  short  locks  was 
offset  bv  the  additional  time  spent  by  the  transaetior s 
waiting  for  that  lock. 

In  [MUN77]  several  parameters  and  concurrency  oortrol 
alternatives  were  explored  by  means  of  a  simulatior  model. 
In  that  simulatior  ,  alternate  methods  for  choosing  a  vic¬ 
tim  in  deadlock  resolution  were  explored.  The  results  of 
the  simulatior  showed  that  three  methods  for  selecting  a 
victim  were  superior:  1)  the  victim  should  be  the  process 
which  accessed  the  least  amount  of  data,  ?)  the  victim 
should  be  the  process  which  held  the  fewest  number  of 
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locks;  or  3)  the  victim  should  be  the  process  which  had 
used  the  least  amount  of  computer  resources. 

In  addition  to  deadlock  resolution,  the  [MUN77]  simu¬ 
lation  was  used  to  study  the  optimum  number  and  size  of 
the  lockable  data  units  in  the  database.  The  authors  con¬ 
cluded  that  the  units  of  locking  should  be  very  small. 
However,  that  conclusion  was  not  based  on  a  fixed  applica¬ 
tion  environment.  Instead,  the  sizes  of  the  transaction 
were  made  smaller  as  the  sizes  of  the  locks  were  reduced. 
Thus  whether  the  observed  increase  in  parallelism  was  due 
to  the  smaller  transactions  or  the  smaller  locks  is 
unclear.  Two  other  problems  with  that  study  were  that 
only  the  CPU  utilization  was  considered  and  that  the  CPU 
resources  of  their  model  were  effectively  considered 
in  f in i te  . 

In  Chapter  2,  a  simulation  model  is  used  to  further 
study  locking  granularity,  optimum  lock  duration  and  a 
variety  of  other  factors. 

3.2.  Distributed  Databases 

Recently,  considerable  attention  has  been  devoted  to 
the  development  and  use  of  distributed  databases  [LBL76, 
LRL77 ,  LRL791.  Ir  siK;h  an  environment,  the  data  is  dis¬ 
tributed  across  a  network  of  computer  systems.  The  poten- 


tial  benefits  of  such  distribution  include  sharing  of  data 
across  differort  computer  sites,  increased  parallelism  ir 
accessing  the  database,  locatirg  data  closer  to  users  and 
increased  reliability. 

However,  one  of  the  major  problems  with  a  distributed 
database  is  the  development  of  a  concurrency  control 
scheme  to  insure  database  consistency  during  multiple  user 
updates  [STON771.  Concurrency  control  schemes  for  a  cen¬ 
tralized  database  do  not  always  extend  to  a  distributed 
database . 

For  example,  in  a  centralized  database,  a  transaction 
can  request  all  of  its  locks  at  the  beginning  of  its  pro¬ 
cessing  and  release  them  at  the  end  [CHAM7^].  In  this 
scenario,  the  locks  are  acquired  in  ore  atomic  action.  If 
one  lock  is  denied,  all  locks  are  denied  and  the  entire 
lock  acquisition  step  is  repeated.  Note  that  in  this 
scenario,  deadlock  is  impossible. 

In  a  distributed  database,  however,  locks  may  have  to 
be  obtained  at  distinct  computer  sites.  Ever'  though  the 
lock  acquisition  at  each  site  is  atomic,  deadlock  can 
still  occur  because  ore  processing  unit  does  r.ot  access 
the  entire  database.  Cor  currency  control  cor  sider  at.  i  or  s 
require  that  the  different  processing  units  communicate 
with  each  other.  The  communication  must  be  used  either  to 
centralize  the  concurrency  control  functions  or  to  prevent 


or  detect  a  decentralized  deadlock. 


Several  solutions  to  the  concurrency  control  problems 
for  distributed  databases  have  beer'  proposed  [BERN77, 
ROSE77,  GRAY78,  MEN A 73  and  STON78].  To  evaluate  the  per¬ 
formance  of  the  different  proposals,  the  number  of  mes¬ 
sages  which  must  be  sent  for  concurrency  control  are 
counted.  In  [BERN77]  it  is  shown  that  if  the  transactions 
are  known  in  advance  (i.e.  only  certain  known  types  of 
transactions  access  the  database),  different  types  of  con¬ 
currency  control  can  be  used  for  different  types  of  tran¬ 
sactions  and  thereby  further  reduce  the  network  con¬ 
currency  control  traffic. 

Unfortunately,  a  count  of  overhead  message  traffic 
does  not,  by  itself,  determine  the  effects  of  the  con¬ 
currency  control  on  the  overall  performance  of  the  distri¬ 
buted  database  system.  Other  factors  such  as  overall  sys¬ 
tem  load,  the  amount  of  non-local  processing,  and  the 
scheduling  of  transactions  must  also  be  considered. 

In  Chapter  3,  a  simulation  model  is  used  to  examine 
the  effects  of  these  factors  as  well  as  the  effects  of  the 
message  traffic. 

In  a  distributed  database,  the  same  data  may  be 
stored  at  several  computer  sites.  These  multiple  copies 
create  additional  concurrency  control  problems  in  that  the 
copies  must  be  kept  mutually  consistent  durirg  multiple 
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updates.  (The  simulations  ir  chanter  7  do  rot  explicitly 
model  the  multiple  copy  undate  scenarios.  However,  some 
of  the  results  of  the  study  car  be  applied  to  the  multiple 
copy  update  problems.) 

Other  studies  do  directly  model  the  multiple  copy 
update  problems  but  do  rot  address  the  internal  database 
consistency  issues.  In  [GRAP7b],  different  algorithms  for 
multiple  copy  consistency  are  analysed  in  terms  of  the 
performance  of  a  distributed  database  management  system. 
In  [GARC78],  a  simulation  model  is  used  to  compare  the 
effects  of  two  algorithms  [ALSB76,  TH0M7S1  or  the  overall 
performance  of  the  distributed  database  system.  Both  stu¬ 
dies  show  that  under  a  wide  variety  of  assumptions  a  "pri¬ 
mary  copy  model'1  is  better  for  maintaining  multiple  copy 
consi stenc v .  The  primary  site  model  basically  implies 
that  the  control  of  updates  to  the  different  copies  is 
channelled  through  a  single  or  primary  copy  of  the  data¬ 
base. 

4.  OVERVIEW 

This  thesis  will  analyze  the  effects  of  concurrency 
control  or  the  performance  of  both  centralized  ar.d  distri¬ 
buted  databases.  In  both  cases,  simulatior  models  are 
used  to  study  the  tradeoffs  between  increased  parallelism 
and  increased  locking  overhead. 
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One  parameter  of  primary  interest  is  the  locking 
granularity.  Locking  granularity  refers  to  the  size  of  a 
lockable  unit  or  granule  which  covers  a  portion  of  the 
database.  Locking  granularity  car:  be  extremely  fine  (i.e. 
one  lock  is  associated  with  each  sector  of  a  disk).  Or, 
locking  granularity  could  be  extremely  coarse  (i.e.  one 
lock  is  associated  with  each  disk  drive). 

In  Chapter  ?,  an  extensive  simulation  model  is 
presented  which  explores  a  large  class  of  concurrency  con¬ 
trol  alternatives.  The  model  is  par ameter  i  zed  to  provide 
insights  into  the  locking  parameters  for  a  wide  variety  of 
database  systems.  The  simulation  experiments  study  lock¬ 
ing  granularity,  the  overhead  costs  of  locking,  the  tran¬ 
saction  types  and  sizes,  a  locking  hierarchy,  and  the 
times  when  locks  are  acquired.  Most  of  these  results  have 
been  published  previously  [RIES77,  RIES79]. 

In  Chapter  3,  the  simulation  models  are  extended  to 
distributed  database  systems.  These  experiments  study  the 
effects  or:  performance  of  locking  granularity,  four  dis¬ 
tributed  concurrency  control  algorithms,  the  transaction 
types  and  sizes,  ar.d  various  network  related  parameters. 

In  Chapter  Jl  ,  the  major  results  these  studies  are 
summarized  and  several  directions  for  future  research  are 


suggested . 


CHAPTER  2 


CENTRALIZED  DATABASE  SYSTEMS 


1-  INTRODUCTION 

In  order  to  insure  the  consistency  conditions  dis¬ 
cussed  in  chapter  1 ,  a  variety  of  concurrency  control 
mechanisms  [CHAM74,  C0DA71 ,  ESWA76 ,  GRAY75,  GRAY76, 
MACR76,  STEA76,  STON74 ]  have  been  proposed  and  implemented 
in  single  machine  database  management  systems.  In  this 
chapter  the  performance  issues  of  these  types  of  mechan¬ 
isms  are  examined. 

Clearly  there  are  advantages  to  increasing  the  paral¬ 
lelism  in  processing  transactions.  Unfortunately,  the 
price  of  this  increased  parallelism  is  the  increased  over¬ 
head  which  must  be  expended  to  achieve  it.  The  goal  of 
this  chapter  is  to  study  the  tradeoff  between  these  con¬ 
flicting  performance  considerations  or  a  single  machine 
database  management  system. 

In  section  2,  a  simulation  model  is  developed  to 
study  that  tradeoff.  In  section  3,  the  results  of  experi¬ 
ments  with  that  simulation  model  are  reported.  In  addi¬ 
tion,  two  extensions  to  that  model  are  used  to  study 
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altorrate  core  urrer.t  v  cor  trol  mechanisms.  Fir:  ally,  the 
major  corclusicr  s  are  summarized  ir  sectior  U.  Ir.  the 
re mairder  of  this  sectior.,  the  performar.ee  issues  ar.d 
approaches  of  centralize'!  concurrency  cor  trol  are 
rev iewed  . 

1  .  jl  .  Performarce  Issues 

An  evaluation  of  concurrency  cor trol  must  include  an 
analysis  of  the  tradeoffs  between  the  overhead  spent  or. 
locking  versus  the  advantages  of  allowing  mere  parallel 
access  to  the  database.  The  advantages  of  increased 
parallelisms  are  in  terms  of  better  user  resoor.se  time  ar.d 
increased  machine  utilization. 

The  amount  of  overhead  spent  or  locking  is  dependent 
on  several  parameters  of  the  concurrency  control  mechan¬ 
ism.  These  parameters  include  the  size  of  a  lockable 
unit,  the  costs  of  setting  and  releasing  locks,  the  pro¬ 
portion  of  resources  required  for  locking  and  the  length 
of  time  for  which  the  locks  are  held.  Each  of  these 
parameters  is  considered  in  turn. 


1.1.1.  Lock  1  r  g  Grnrularity 

All  of  the  cor currerv  v  cor  trol  mec  hanises  involve  the 
locking  of  some  physical  or  logical  portior  of  the  data¬ 
base.  The  smallest  portior  of  the  database  which  can  be 
locked  is  referred  to  as  a  "granule” .  The  size  of  a 
granule  varies  in  different  database  management  systems. 
In  some  systems  (CODASYL  [CODA731,  System  R  [ASTR76], 
DMS-1100  [GRAY75])  the  granule  may  be  as  small  as  ore 
record.  Other  systems  (System  2000  [SPIT76],  IMAGE 

[HEWL77])  support  ore  granule  covering  the  entire  data¬ 
base.  Still  other  systems  (DBMS-11  [DEC77]*  LSL  [LIPS76]) 
support  intermediate  sized  granules  such  as  files  or 
areas  . 

There  is  a  clear  tradeoff  between  locking  overhead 

**  , 

and  parallelism  based  on  the  locking  granularity.  Fire 
granularity  allows  a  higher  degree  of  parallelism  at 
greater  cost  in  managing  locks.  For  example,  assume  that 
a  granule  corresponds  to  a  reecrrd  in  a  database.  Then  the 
transactions  may  run  in  parallel  without  corflict  as  long 
as  they  access  distinct  records.  However,  the  database 
system  must  be  prepared  to  handle  as  many  locks  as  there 
are  records  in  the  database. 

Coarse  granularity,  or  the  other  hand,  inhibits 
parallelism  but  minimizes  management  of  locks.  If  the 
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granule  is  cor  si  Here  i 
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hierarchy  [GRAY76  ] . 

In  a  lock  hierarchy, 

a  tree  strut ture 

of  locks  is  supported 

A  tran sac 

tior:  car. 

either*  exuli- 

citlv  hold  locks  or  lower  branches  of  the  tree,  or  i m d li¬ 
cit  1  y  hold  those  locks  by  explicitly  locking  an  ancestor 
node  common  to  all  of  the  lower  branches. 

With  such  a  hierarchy,  the  costs  of  locking  for  large 
trar.  sac  tior  s  may  be  greatly  reduced  since  it  is  cheaper  to 
set  one  large  lock  than  to  set  many  small  locks.  However, 
the  locking  costs  for  the  trar  sac ti or. s  using  small  locks 
may  increase.  Those  transactions  would  have  to  set  all 
the  locks  in.  the  path  f rom  the  leaves  to  the  root  of  the 
tree.  Again  a  tradeoff  is  observed  between  the  parallel¬ 
ism  allowed  and  the  locking  overhead. 

For  example,  consider  a  two-level  hierarchy  where  one 
lock  at  the  top  level  eortrols  access  to  the  entire  data¬ 
base  and  many  (more  than  ore)  locks  at  the  lower  level 
control  access  to  individual  "parts"  of  the  database,  A 
transaction  which  accesses  the  entire  database  ear 
exclusively  lock  the  one  top  level  lock.  Without  a  lock 
hierarchy  and  just  the  small  locks,  it  would  be  much  more 
expensive  for  that  transaction  to  lock  all  of  the  small 


locks  . 


The  above  lock  hierarchy,  however,  increases  the 
locking  overhead  for  the  transaction  which  just  access  ore 
"part"  of  the  database.  That  transaction  must  set  the 
higher-level  lock  in  an  "intention"  mode  [GRAY76]  (imply¬ 
ing  that  explicit  locking  is  required  at  the  lower  level) 
and  still  lock  the  individual  part  of  the  database.  Thus, 
that  transaction  sets  two  locks.  Without  a  lock  hierarchy 
and  just  the  small  lock,  that  transaction  would  set  only 
one  lock. 

1.1.2.  Lock i  ng  Overhead 

Concurrency  control  overhead  refers  to  the  amount  of 


computer 

r esources 

utilized  by 

the 

locking 

mechan i sm . 

This  "overhead"  can 

be 

thought 

o  f 

as  the 

difference 

between 

the  resources 

required 

by 

a  transaction  in  a 

multi-user  system  and  the  resources  that  would  be  required 
if  the  transaction  could  be  run  as  the  only  user  of  the 
database.  The  locking  mechanisms  must  comnete  with  the 
transactions  for  memory,  CPU  cycles,  and  I/O  channels. 
Thus,  as  a  locking  mechanism  increases  in  complexity  and 
requires  more  resources,  it  will  start  to  interfere  with 
the  running  of  the  transactions. 


The  ratio  of  resources  spent  for  locking  to  resources 
spent  for  processing  transactions  is  critical.  For  exam¬ 
ple,  a  ratio  of  one  implies  that  it  is  as  expensive  to 
lock  a  granule  as  it  is  to  process  the  data  in  that 
granule.  In  this  case,  two  transactions  could  have  been 
run  without  locking  in  the  time  it  takes  a  transaction  to 
set  its  locks,  process  the  data,  and  release  the  locks.  A 
less  expensive  concurrency  control  which  only  allowed  half 
of  the  parallelism  might  provide  the  same  throughput. 

Lock  Duration 

Another  factor  which  affects  the  degree  of  parallel¬ 
ism  and  the  cost  of  concurrency  control  is  the  time  period 
for  which  the  locks  are  held.  Two  simple  procedures  which 
insure  that  a  transaction  is  two-phased  (See  Chapter  1) 

are : 

1)  set  all  locks  at  the  beginning  of  a  transaction  or 

2)  hold  all  the  locks  until  the  end  of  a  transaction . 

If  the  second  option  is  chosen,  the  locks  can  still 
be  preclaimed  as  in  option  1  or  requested  and  granted  as 
reeded  by  the  transaction. 

A  performance  tradeoff  is  again  possible.  By  not 
locking  resources  until  they  are  required,  additional 


parallelism  is  possible.  However,  the  locking  overhead 
costs  are  increased  by  two  factors.  First,  the  con¬ 
currency  control  mechanism  must  check  for  deadlock 
[C0FF71].  Second,  if  deadlock  is  detected,  a  transaction 
may  have  to  be  restarted.  The  resources  already  used  by  a 
restarted  transaction  should  also  be  included  as  overhead 
costs  since  they  would  not  have  been  used  if  the  transac¬ 
tion  was  run  by  itself. 

In  summary,  the  important  performance  parameters  are 
locking  granularity,  locking  overhead,  and  lock  duration. 

1*2.  Loc^ii!!^ 

Two  general  options  have  been  proposed  for  single 
machine  concurrency  control  --  physical  locks  and  predi¬ 
cate  locks. 

1  Locks 

Physical  locks  are  placed  on  records,  pages,  seg¬ 
ments,  files,  areas  or  the  entire  database.  In.  this  case, 
a  "granule”  refers  to  a  physical  portion  of  the  database. 

With  physical  locks,  a  data  manipulation  command  can¬ 
not  proceed  if  a  granule  it  needs  is  locked  by  someone 
else.  Various  strategies  for  requesting  and  releasing 


locks  have  been  suggested  [CHAM71*,  GRAY76,  STEA76  , 
MACR76].  Some  of  these  strategies  require  the  detection 
resolution  of  deadlock. 

The  basic  idea  behind  physical  locking  is  straight 
forward.  If  a  transaction  needs  to  read  a  portion  of  the 
database  but  not  write  it,  a  read  or  shared  lock  must 
first  be  obtained  on  a  granule  which  physically  covers 
that  portion  of  the  database.  Other  transactions  which 
also  read  that  portion  or  a  portion  covered  by  the  same 
granule  can  share  that  lock. 

If  all  or  a  portior:  of  the  granule  is  to  be  updated, 
an  exclusive  lock  must  be  obtained  which  cannot  be  shared 
by  other  running  transactions.  The  two-phase  requirement 
insists  that  no  locks  can  be  released  until  the  transac¬ 
tion  has  acquired  all  of  the  locks  that  it  needs. 

1.2.?.  Predicate  Locks 

A  predicate  lock  can  be  set  or.  the  exact  portior  of 
the  database  which  is  to  be  accessed.  The  portior.  of  the 
database  which  is  locked  is  determined  by  predicates  or 
qualifications  associated  with  the  transaction.  The 
predicate  (i.e.  ,fall  records  with  date  field  values  in 
June,  1976”)  restricts  the  transaction  to  a  logical  subset 
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of  the  database.  Such  locks  do  rot  necessarily  correspond 
to  ary  physical  portior  of  the  database.  This  approach  is 
explored  in  [FLOR74,  STON74,  ESWA76]. 

In  predicate  locking,  a  predicate  corr espond irtg  to  a 
selection  criteria  of  a  transaction  is  submitted  to  the 
locking  mechanism.  If  the  locking  mechanism  can  "prove11 
that  a  transaction  does  not  conflict  with  any  running 
transactions ,  the  locks  are  granted.  Otherwise,  the 
requesting  transaction  must  wait.  A  propositional  logic 
"theorem  prover"  can  be  used  to  prove  that  two  transac¬ 
tions  do  not  conflict.  The  sophistication  of  the  theorem 
prover  can  be  varied  depending  on  the  tradeoff  between 
increased  parallelism  and  CPU  recourses  used  for  locking. 

The  granularity  in  predicate  locking  also  varies. 
For  example,  a  predicate  such  as  ”employee__no=  1 23^ "  might 
restrict  the  transaction  to  one  record.  On  the  other 
hand,  a  predicate  such  as  "depar tmer t- er g in eer in g"  might 
represent  hundreds  of  records.  Notice  that  predicate 
locks,  like  physical  locks,  can  be  acquired  throughout  the 
duration  of  a  transaction. 

Predicate  locking  has  two  obvious  advantages.  One  is 
that  a  predicate  lock  can  accurately  describe  the  exact 
logical  portior  of  the  database  that  is  to  be  accessed  by 
a  transaction.  The  second  is  that  the  cost  of  setting 


such  a  lock  depends  or.  the  number  of  simultaneous  transac¬ 
tions  actually  submitted  and  not  or  the  amount  of  data 
that  is  actually  accessed. 

However ,  the  predicate  locking  mechanism  may  need¬ 
lessly  keep  a  transaction  from  running.  Suppose  the 
predicate  " AGE>2 9M  has  been  granted  a  lock  for  a  running 
transaction  and  that  another  transaction  issues  the 
request  "AGE<31ff.  If  no  ore  with  AGE=30  were  in  the  data¬ 
base,  both  transactions  could  be  allowed  to  run.  But  the 
predicate  locking  mechanism  would  require  that  the  secord 
transaction  waits. 

Thus,  predicate  locking  may  reduce  corcurrer  cy  con¬ 
trol  overhead  at  the  expense  of  allowing  less  parallelism 
in  accessing  the  database. 

2.  MODEL.  DESCRIPTION 

A  simulation  model  is  used  to  investigate  the  tra¬ 
deoffs  between  concurrency  control  overhead  and  increased 
parallelism.  The  model  is  described  by  first  explaining 
the  flow  of  transactions  around  a  closed-loop  model.  Next 
the  model  input  and  output  parameters  are  discussed. 
Finally,  the  allocation  and  competition  for  resources  in 
the  model  are  described. 


2.U  Transaction  F^ow 

The  running  of  transactior s  against  a  database  is 
simulated  by  assuming  there  are  a  fixed  number  of  transac¬ 
tions  which  are  cycled  continuously  for  TMAX  time  units 
around  the  model  shown  in  figure  2-1.  A  transaction  goes 
through  the  following  steps: 

1)  Arrive  on  the  pending  queue 

2)  Acquire  locks 

3)  Process  I/O  requests 

4)  Process  CPU  requests 

5)  Release  locks 

6)  Generate  a  new  transaction  and  return  to  step  1 

These  steps  are  explained  in  more  detail  below. 

Initially,  the  trap,  sac  tion  s  arrive  ore  time  unit 
apart  and  are  placed  on  the  pending  queue.  The  transac¬ 
tion  is  removed  from  the  PENDING  queue  and  all  required 
locks  are  requested.  If  the  locks  are  granted,  the  tran¬ 
saction  is  placed  or.  the  bottom  of  the  I/O  queue.  If  the 
locks  are  denied,  the  transaction  is  placed  on  the  bottom 
of  a  BLOCKED  queue.  The  blocking  transaction  is  recorded. 
(The  description  of  which  locks  are  required  by  a 


transaction  is  given  in  section  2.3.)  Note  that  no  locks 
are  held  while  or  the  blocked  queue  so  deadlock  is  impos¬ 
sible. 

After  completing  the  I/O  required,  the  trar: sactior:  is 
placed  on  the  bottom  of  the  CPU  queue. 

After  completing  the  CPU  required,  the  transaction 
releases  its  locks.  At  this  point  a  new  transaction  is 
added  to  the  end  of  the  PENDING  queue.  (Note  that  each 
transaction.  goes  through  one  I/O  phase  and  one  CPU  phase. 
Although  they  are  sequential  in.  the  model,  the  result 
would  be  the  same  if  each  transaction  were  to  go  through 
many  I/O  -  CPU  phases  in  a  single  cycle.)  All  transactions 
that  were  blocked  by  the  completed  transaction  are  placed 
on  the  front  of  the  PENDING  queue. 

2.2.  Model  Par ameters 

The  input  parameters  can  be  divided  into  those  that 
characterize  the  workload,  and  those  that  characterize  the 
system.  Workload  Darameters  describe  the  database  and  the 
tran sac tion s  that  are  run  against  that  database.  System 
parameters  describe  the  computer  system  and/or  the  data¬ 
base  management  system  characteristics.  The  output  param¬ 
eters  characterize  the  throughput,  overhead  and  utiliza¬ 
tion  of  the  system.  These  parameters  are  all  described  in 


more  detail  below. 


2.2.1.  Workload  Parameters 

The  workload  input  parameters  are  summarized  in  Table 
2-1.  The  number  of  tr an saetion s ,  NTRAN,  in  the  system  is 
fixed.  The  closed  loop  model  could  have  two  interpreta¬ 
tions.  As  each  transaction  completes,  the  user  submits 
another  transaction.  Alternately,  the  transactions  could 
be  viewed  as  application  programs.  When  one  of  these  com¬ 
pletes,  another  apDlication  program  enters  the  system  to 
take  its  place. 

The  database  size,  DBSIZE,  refers  to  the  number  of 
entities  in  the  database.  In  this  model,  the  database  is 
an  abstract  collection  of  entities.  An  entity  can.  be 


Table  2-1  Workload  Parameters 


Parameter 


Description 


NTRAN 

DBSIZE 

RAD 

AMEAN 

BMEAN 


ALPH 

LKPLMT 


number  of  transactions 
number  of  entities  in  the  database 
a  transaction  size  parameter, 
mean  for  exponential  distribution 
of  transaction  size. 

another  mean  for  exponential  distribution 

of  transaction  size.  Used  with  AMEAN  for 

hyper-ex  do rertial  distribution 

of  transaction  sizes. 

cut  of  proportion  between.  AMEAN 

and  BMEAN. 

lock  placement  assumption,  (see  below) 


Li 
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thought  of  as  the  unit  of  data  moved  by  the  operating  sys¬ 
tem  into  the  database  system  buffers. 

In  the  simulation,  three  types  of  distributions  for 
tran  sac  tior.  sizes  are  used.  The  size  of  a  transaction 
refers  to  the  number  of  entities,  NE,  touched  or  accessed 
by  a  Riven  transaction.  The  number  of  entities  "touched” 
or  accessed  by  a  Riven  transaction  completely  determines 
the  amount  of  I/O,  CPU  and  lock  resources  required  by  that 
transaction.  In  the  simplest  case,  the  sizes  of  the  tran¬ 
sactions  are  uniformly  distributed  by  the  RAD  parameter. 

i.  n 

The  number  of  entities  touched  by  the  i^  transaction  is 
given  by: 


NE.=i*RADf fori= 1 ,  .  .  .  f NTRAN 

This  distribution  reflects  a  workload  with  a  uniform  mix 
of  different  sized  transactions. 

The  second  distribution  of  transaction  sizes  is 
exponential.  The  average  transaction  size  is  determined 
by  the  AMFAN  parameter.  In  this  case, 

NE^  =  -AMF.AN*log(rrd) 

where  rnd  is  a  uniformly  distributed  random  number  between 
zero  and  ore.  This  distribution  reflects  a  workload  where 
most  of  the  transactions  are  small  a  very  few  transactions 
are  large. 


V 


The  final  distributior  used  is  hyper-ex  nor er  ti al  with 


three  parameters,  AVE4N,  RMEAN,  nr d  ALPH.  In  this  distri¬ 
butior:,  some  (ALPH  x  100  percent)  of  the  transactions  have 
sizes  which  are  ex  per' er.  t  i  a  1 1  y  distributed  with  a  mean  of 
BMF.AN.  The  other  transactions'  have  sizes  which  are 
exponentially  distributed  with  mean  AMEAN.  In  this  case, 

NEi=-BMEAN*lofi(rrd1  ) 

if  r  nd2  <  ALPH  or 


NEi  =  -AMEAN*l0R(rnd1  ) 

if  r rd2  >=  ALPH 

where  rn.dl,  and  rnd2  are  independent  random  variables 
similar  to  rnd  •  This  distributior.  is  used  to  model 
scenarios  where,  for  instance,  most  of  the  transactions 
are  extremely  small  and  only  touch  a  few  records  or  narcos 
of  a  database,  while  a  few  tr  an  sac  tior.s  must  access  a  very 
large  number  of  records.  Note  that  the  exponential  dis¬ 
tribution  is  just  a  special  case  of  the  hyper-ex  per ertial 
distribution  with  an  ALPH  of  zero. 

The  lock  placement  parameter,  LKPL^T,  determines  the 
number  of  locks  that  a  given  transaction  requires.  Three 
different  assumptions  regarding  lock  placement  are  simu¬ 


lated  . 
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With  "well  placed"  locks  (LKPLMT  r  1),  the  number'  of 
locks  required  by  a  reiver,  transactior  is  exactly  propor¬ 
tional  to  the  percentage  of  the  database  touched  or 
accessed  by  the  transactior .  .  For  transaction  i,  the 
number  of  locks,  NL,  is 

NL.=CEILING(NEt*NGRAN/DBSIZE) 

where  NCR AM  is  the  total  number  of  locks  available. 
Hence,  a  transactior:  which  touched  half  of  the  entities  in 
the  database  would  require  half  of  the  possible  database 
locks.  Note  that  this  amounts  to  assuming  that  the 
granules  are  "well  placed",  i.e.  that  the  entities  needed 
by  the  transactions  are  packed  into  as  few  flockablet 
granules  as  possible.  This  assumption  is  reasonable  for 
transactions  which  access  the  database  sequentially. 
Although  sequential  processing  in  database  applications 
has  been  observed  [RODR76],  actual  transactions  may 
require  a  combination  of  sequential  and  random  accesses  to 
the  database. 

Under  a  "worst  case  placement"  assumptior  (LKPLMT  = 
2),  each  transactior  requires  the  maximum  number  of 
granules  possible.  In  this  case 

NL. rMIN(NE.  NGRAN)  . 
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If  the  total  number  of  entities  touched  by  a  giver  trar- 
saetior  ,  NR,  is  greater  than  the  number  of  locks  cover irg 
the  entire  database,  NGRAN,  ther'  in  the  worst  case,  all  of 
the  locks  might  have  to  be  acquired  in  order  to  access  the 
needed  entities.  If  NE  is  less  than  NGRAN,  the  number  of 
locks  that  have  to  be  set  is  bounded  by  the  number  of 
entities,  NE.  Thus,  the  number  of  locks  required  is  the 
minimum  of  the  number  of  locks  for  the  entire  database  and 
the  number  of  entities  touched  by  the  transaction.  This 
assumption  simulates  an  M urccoper at i veM  trarsaetior  ,  i.e. 
one  whose  access  pattern  is  the  worst  possible  from  the 
lock  mechanism  point  of  view.  This  scenario  is  the  oppo¬ 
site  extreme  of  the  ’’well  placed”  assumption. 

Under  a  ’’random  access  placement”  assumption,  a 
mean-valued  formula  is  used  to  estimate  the  number  of 
locks  required  for  each  transaction.  The  number  of  locks 
required  under  this  assumption  is  analogous  to  the  number 
of  blocks  accessed  when  randomly  selecting  records  from  a 
blocked  file.  The  formula  for  this  number  and  its  deriva¬ 
tion  are  given  in  [YA0771.  This  model  accurately  reflects 
random  processing  where  the  probability  of  accessing  ary 
entity  is  the  same  and  independent  of  any  previous  enti¬ 
ties  accessed.  Let  DBSIZE  be  the  n umber  of  er titles  in 
the  database,  NGRAN  be  the  total  number  of  locks,  ard  p  be 
the  number  of  entities  per  lock  (-DRSIZE/ NGRAN)  .  Then  a 
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transaction  which  accesses  NE  entities  requires 

r DRSIZE-p  1 


NCR AM  * 


1  - 


'ME 

-DRSIZE' 

ME 


locks.  The  expressions  p  and  rePresent 
the  number  of  different  ways  ME  entities  can  be  selected 
from  DBSIZE-p  and  DBSIZE  entities  respectively.  The 
derivation  of  this  formula  is  identical  to  the  derivation 
in  [YA077]  and  is  not  repeated  here. 


2.2.2.  System  Parameters 

The  system  parameters  are  listed  in.  Table  2-2.  The 
number  of  granules,  NGRAN,  into  which  the  database  is 
divided  is  varied  from  one  to  the  number  of  entities  in 
the  database,  DBSIZE.  A  granule  is  the  unit  which  is 
locked  by  a  transaction.  Each  granule  is  assumed  to  be 
the  same  size.  Hence,  if  NGRAN  =  1,  a  granule  is  the 
entire  database  of  DBSIZE  entities.  If  NGRAN  =  2,  a 
granule  is  DBSIZE/2  entities.  If  NGRAN  =  DBSIZE,  each 
granule  is  1  entity. 


The  CPU  costs  for  processing  a  transaction  are  deter¬ 
mined  by  the  CPU  RATE  parameter.  The  CPURATE  refers  to  the 
CPU  resources  required  for  procossirg  ore  entity  of  the 
database  where  CPU  resources  are  in  time  units  of  the 


Table  2-2  System  Parameters 


Par ameter 


Description 


NCR  A  M 

CPURATE 

10 RATE 

LCPURATE 

LIORATE 

I00VLP 


number  of  lockable  granules 
CPU  time  to  process  ore  entity 
I/O  time  to  process  ore  entity 
CPU  rate  to  process  ore  lock 
I/O  rate  to  process  ore  lock 
number  of  simultaneous  I/O 
operations  permit tei 


simulation . 


Note  that  these  are  the  resources  for  pro¬ 


cessing  the  tr  an  sac  t  i  or:  s  and  do  rot  include  any  costs  for 


processing  the  locks. 


Similarly,  the  I/O  costs  for  processing  a  transaction 
are  determined  by  the  IORATE  Parameter.  Note  that  the 
CPURATE  and  IORATE  could  have  also  been  considered  as 
workload  parameters  because  in  many  cases  they  are  appli¬ 
cation  dependent  [HAWT79]. 


The  lock  CPU  parameter,  LCPURATE,  refers  to  the  CPU 
resources  required  to  request  (and  set/release)  a  lock  for 
one  granule. 


Similarly,  LIORATE  determines  the  I/O  overhead  for 
setting  one  lock.  For  some  OHMS  systems,  lock  tables  are 
kept  entirely  ir.  main  memory.  These  systems  are  modeled 
by  a  LIORATE  of  zero.  On  the  other  hand,  a  database  sys¬ 
tem  which  has  as  many  locks  as  pages  in  the  database,  may 
have  to  keep  lock  tables  or  secondary  storage  devices. 


Such  systems  would  have  a  nor-zero  LIORATE  parameter. 


The  I/O  overlap,  IOOVLP,  indicates  how  many  simul¬ 
taneous  I/O  operations  are  possible.  This  parameter  is  a 
surrogate  for  the  number  of  independent  paths  used  between 
main  memory  and  secondary  storage  (and  hence  for  how  much 
I/O  activity  can  go  on  in  parallel). 

2.2.3.  Output  Parameter s 

The  performance  measurements  shown  in  Table  2-3  are 
generated  by  each  simulation  run.  The  total  CPU  time, 
TCPU,  refers  to  the  number  of  time  units  in  which  the  CPU 
is  busy.  During  TMAX  -  TCPU  time  units  the  CPU  is  idle. 


The  total  I/O  units,  TIO,  is  the  number  of  time  units 
in  which  the  I/O  resources  are  busy.  The  total  I/O  units 
utilized  can  become  larger  than  TMAX  if  the  I/O  overlap 


Table  2-3  Output  Parameters 
Par ameter  Description 


TCPU 

TIO 

LOCKCPU 
LOCK TO 
USEFULC  P!J 
USEFUL  10 
TRANCOM 
AVERRES 


Total  time  CPU  active 
Total  time  I/O  active 
CPU  overhead  for  locking 
I/O  overhead  for  locking 
CPU  time  for  transactions 
I/O  time  for  transactions 
number  of  transactions  completed 
average  response  time 
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parameter  is  greater  than  1.  In  fact  TIO  is  bounded  above 
by  TM  AX  *  IOOVLP . 

The  CPU  units  used  for  lock  management  are  recorded 
in  LOCKCPU  while  the  I/O  units  used  for  locking  are 
recorded  in  LOCKIO. 

The  useful  computer  utilization,  USEFULCPU  and  USEFU- 
LIO,  refer  to  the  net  resources  used  for  transaction  pro¬ 
cessing.  These  measurements  reflect  the  transaction  pro¬ 
cessing  time  without  the  concurrency  control  overhead. 
Note  that 

TCPUrLOCKCPU+USEFULCPU 

TIO=LOCKIO+LOCKCPU . 

The  total  number  of  transactions  completed  at  the  end 
of  a  simulation  run,  TRANCOM,  and  the  average  response 
time,  AVERRES,  are  also  recorded.  The  time  when  each 
transaction  is  first  placed  or  the  pending  queue  is  con¬ 
sidered  an  arrival  time  for  that  transaction.  The  differ¬ 
ence  between,  that  time  and  the  time  when  that  transaction 
releases  its  locks  is  called  the  response  time.  Some 
transactions  may  have  started  but  not  finished  at  the  com¬ 
pletion  of  the  simulation  run.  These  transactions  are  not 


included  in  the  computation  of  TRANCOM  or  AVERRES. 


2.3.  Resource  Al_10£ati_on  a£d  Usat’e 

The  above  parameters  completely  determine  the 
resources  required  by  each  transaction.  These  resources 
are  summarized  in  Table  2-4. 


The  CPUTIME  represents  the  total  number  of  time  units 
that  a  transaction  would  be  on  the  CPU  queue  if  it  were 
running  by  itself.  However,  if  there  are  N  transactions 
on  the  CPU  queue,  the  CPU  is  multiplexed  among  those  N 
transactions.  For  example,  if  there  are  always  2  transac¬ 
tions  on  the  CPU  queue,  a  transaction  with  a  CPUTIME  =  50, 
would  remain  on.  the  CPU  queue  for  100  time  intervals. 


The  IOTIME  is  similar,  except  for  the  effect  of  the 
I00VLP  parameter.  If  there  are  N  transactions  on  the  I/O 
queue,  each  transaction.  pnogresses  min  ( 1  , 100VLP/N  )  time 


Table  2-4  A  Transaction 


RESOURCE 


FORMULA 


NE 

ML 

CPUTIME 
IOTIME 
LOCKIOTIME 
LOCKC  PUT  I  ME 


=  function(RAP) 

or  function ( AME AM , RMEAN , ALPH ) 

=  function ( NE ,  LKPLMT,  DBSIZE) 
=  NE  *  CPU  RATE 
=  NE  *  IORATE 
=  NL  *  LI  OR  ATE 
=  NL  *  LCPURATE 


units.  The  progress  is  bounded  above  by  1  to  simulate  ore 
transaction  having  only  one  outstanding  I/O  request  at  a 

time . 


The  locking  mechanisms  are  giver  a  higher  priority 
for  the  I/O  and  CPU  resources  than  the  active  transac¬ 
tions,  Also  rote  that  these  costs  are  repeated  each  time 
a  transaction  requests  its  locks.  For  example,  suppose  a 
transaction  requests  locks,  they  are  denied,  and  the  tran¬ 
saction  is  placed  on  the  blocked  queue.  Later  that  tran¬ 
saction  is  removed  from  the  blocked  queue,  the  locks  are 
requested  again,  and  this  time  they  are  granted.  The 
total  lock  overhead  associated  with  this  transaction  is 
twice  NE  times  the  lock  rates. 

Two  approaches  are  used  to  simulate  the  competition 
for  the  available  granules.  Under  both  approaches,  the 
decision  to  grant  or  deny  a  lock  request  is  based  or 
another  uniformly  distributed  random  variable,  rrd3. 

Under  one  approach,  the  granules  for  each  transaction 
are  considered  to  be  completely  ur.corr el ated .  Let  CRL  be 
the  number  of  locks  currently  held  by  the  active  transac¬ 
tions.  Then  a  transaction  reeding  NL  locks,  has  those 


locks  granted  if 
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NGRAN-CRL 
.0  n  NL 

rrd3  > 

LNL 

The  above  expression  is  simply  the  number  of  ways  of 
choosing  NL  locks  from  those  that  are  already  still 
unclaimed  divided  by  the  number  of  ways  of  chosen  the  NL 
locks  from  all  of  the  locks. 

Under  the  well-placed  lock  assumption,  the  above  for¬ 
mula  actually  penalizes  finer  granularity.  For  example, 
doubling  the  number  of  locks,  (2  *  NGRAN),  could  result  in 
also  doubling  NL  and  CRL.  The  number  of  locks  for  a  tran¬ 
saction,  NL,  would  be  doubled  if  a  transaction  touched  all 
of  the  entities  covered  by  a  given  lock.  But  then,  the 
probability  of  a  successful  lock  request  is  actually 
smaller  due  to  the  finer  granularity  because 

_2*NGRAN-2*CRL  NGRAN-CRL 
L2*NE  °NE 

2*NGRAN  r NGRAN  * 

^2*NE  ^NE 

The  right  hand  side  is  the  probability  of  obtaining  NL 
locks  with  the  original  granularity  while  the  left  hand 
term  is  the  same  probability  if  the  number  of  locks  were 
doubled . 

To  avoid  this  bias  under  the  well-placed  lock  assumc- 
tion ,  a  second  approach  to  computing  lock  conflicts  is 
used.  With  this  approach  it  is  assumed  that  the  first 
requested  granule  is  uncorrelated  with  any  of  the  granules 


v 


which  are  already  locked.  Furthermore,  the  additioral 
requested  granules  are  assumed  to  be  distinct  from  the 
already  locked  granules.  Under  this  assumption,  the  locks 
are  granted  if 


rnd3 


_  CRL_ 

(ngra‘n-ne+TT# 


Under  either  approach,  if  the  locks  are  granted,  CRL 
is  incremented  by  NL.  If  the  locks  are  denied,  ore  of  the 
active  transactions  is  picked  as  the  blocking  transaction. 
The  probability  that  a  transaction ,  say  Tj  is  the  blocking 
transaction  is  NLVCRL;  i.e.  is  directly  proportional  to 
the  number  of  locks  held  by  the  blocking  transaction. 


3.  RESULTS  and  DISCUSSION 

In  this  section  the  results  of  running  the  simulation 
under  a  wide  variety  of  parameter  settings  are  reported. 
First,  the  results  of  some  initial  runs  of  the  simulation 
are  explained.  Next  the  effects  of  varying  the  workload 
and  system  parameters  are  reported.  Finally,  the  effects 
of  two  changes  to  the  basic  simulation  model  are 


descr i bed . 
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3.1.  An  I[!_iti_al^  §.ci®H§rj2 

The  simulation  is  initially  run  with  the  workload 
parameters  shown  in  Table  2-5  for  10,000  (TMAX)  time 
units.  The  system  parameters  for  the  first  run  are  shown 
in  Table  2-6. 

In  this  scenario,  ten  transactions  were  submitted  to 
a  database  of  5000  entities.  The  transactions  required 
from  50  to  500  entities  each  (initially  the  sizes  were 
uniformly  distributed).  (The  simulation  was  also  run  with 
up  to  20  transactions  with  no  appreciable  effect  other 
than  scale  on  the  output  parameters.) 


Table  2-5  Sample  Workload  Parameters 

Parameter  Value 

NTRAN  10 

DBSIZE  5000 

LKPLMT  Well-Placed 

RAD  50 


Table  2-6  Sample  System  Parameters 
Parameter  Value 


NCR  AN 

C  PU  RATE 

IORATE 

LCPURATF. 

LIORATE 

I0OVLP 


1  to  5000 
.05 
.  20 
.01 
.20 
1 


The  locks  were  assumed  to  be  "well-placed"  with 
respect  to  the  accessing  transactions  and  thus  the  tran¬ 
sactions  required  the  smallest  number  of  granules  that 
were  required  to  "cover"  the  touched  entities. 

The  I/O  overlap  parameter  was  set  to  one  which 
results  in.  orly  one  transaction  processing  an  I/O  opera¬ 
tion  at  ore  time.  ^Jote  that  for  this  run  the  I/O  rate  is 
four  times  the  CPU  so  that  this  simulates  an  "I/O  bound" 
application.  The  CPU  cost  of  a  lock  was  1/5  that  required 
to  process  an  entity.  Lastly,  the  I/O  cost  of  a  lock  was 
equal  to  the  I/O  cost  of  ar.  entity.  Hence,  this  initial 
run  simulated  a  lock  table  being  keDt  on  secondary 
storage . 

Intuitively,  these  input  parameters  could  be  inter¬ 
preted  as  followes: 

DBSIZE  is  5  million  bytes  (one  entity  is  1024  bytes) 

Average  transaction  accesses  250,000  bytes  of  data. 

IORATE  of  30  msecs  per  entity  (one  disk  accesses). 

CPURATE  of  7.5  msec  per  entity. 

LIORATE  of  30  msecs  per  lock. 

LCPURATE  of  1.5  msecs  per  lock. 

In  this  interpretation  ore  time  unit  corresponds  to  150 


mill isecords . 
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For  these  simulation  runs,  the  value  TMAX  =  10000  was 
chosen  after  running  simulations  for  various  smaller 
values  including  TMAX  =  2500.  In  all  cases,  no  change 
(except  for  scaling)  was  observed  in  the  output  parameters 
between  TMAX  =  2500  and  TMAX  =  10000.  For  some  of  the 
experiments  discussed  later,  other  values  of  TMAX  were 
required  to  guarantee  convergence.  Keeping  the  other 
parameters  fixed,  the  number  of  granules  was  varied 
between  1  and  5000.  The  output  from  the  simulations  is 
presented  in  Tables  2-7  and  2-B. 

Note  that  the  utilization  of  I/O  resources  for  tran¬ 
saction  processing,  USEFULIO,  peaked  at  40  granules. 
Within  1%  of  this  value  was  reached  with  only  10  locks. 
The  useful  1/0  remained  relatively  constant  until  the  lock 
I/O  costs  start  to  be  a  significant  fraction  of  I/O  time. 
For  a  small  number  of  granules,  high  lock  I/O  cost 
resulted  from  lock  conflicts  which  generated  still  more 
lock  I/O.  (In  an.  actual  impl  emen  ta  t  ion  of  a  locking 
scheme,  a  small  number  of  locks  could  easily  be  maintained 
in  primary  memory.  This  alternative  is  explored  subse¬ 
quently.)  Similaiiy,  the  useful  CPU  time  peaked  at  30 
granules,  ard  again  this  value  was  almost  reached  (within 
1%)  with  as  few  as  10  granules.  These  results  are  por¬ 
trayed  graphically  in  figure  2-2.  The  lock  CPU  costs  were 
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Table  2-7 

CPU  ar.d  I/O  Utilization 
Initial  Scenario 


N°°f_CRANUL‘:S 

OSEFULIO 

USFFULCPU 

LOCK  10 

LOCKCPU 

1 

7041 .957 

1759.906 

1282.000 

12.820 

2 

8376.933 

2091.914 

970.000 

9 . 700 

3 

9002.256 

2237.415 

777 . 000 

7.770 

4 

9030.253 

2258.925 

671 . 000 

6.710 

5 

9273.915 

2304 . 927 

604.000 

6.040 

7 

9433.514 

2309 . 940 

474 . 000 

4.740 

9 

9449 . 087 

2337 . 442 

428 . 000 

4 . 280 

10 

9476 . 130 

2324.941 

437 . 000 

4  .  370 

15 

9425 . 585 

2358.445 

403  -  000 

5.210 

20 

9437.937 

2354 . 943 

396 . 000 

5.280 

30 

9534.303 

2377 . 449 

371 .000 

6.720 

40 

9572.718 

2354.949 

360 . 000 

7 . 900 

50 

9504.073 

2339.950 

360.000 

8.790 

75 

9448. 435 

2332 . 452 

454 . 000 

13.290 

100 

9378.277 

2324.951 

482 . 000 

15 . 430 

125 

9351 . 744 

2316.457 

547 . 000 

20 . 890 

150 

9304 . 128 

2279.96 0 

613.000 

23.700 

200 

9159.688 

22 59.959 

753-000 

30.000 

250 

9110.531 

2249. 964 

806.000 

36.740 

300 

8768.228 

2177.465 

1015.000 

43.470 

500 

8517.21 1 

2097.466 

1  390.000 

69 . 499 

750 

7820.61  1 

1919.974 

1950.000 

94.439 

1000 

7359.828 

1814.976 

2462.000 

123.099 

2500 

4764 . 175 

1  189.989 

4824.000 

241 . 199 

5000 

3408.635 

824 . 992 

6120.000 

305.998 

minimized  with  10  granules.  With  fewer  granules,  the 
request  failure  rate  caused  enough  re-requests  for  locks 
that  the  overall  CPU  costs  for  locking  increased.  With 
more  than  10  granules,  the  reductior  in  lock  request 
failures  did  rot  offset  the  costs  of  setting  the  addi¬ 
tional  locks  required  for  each  transaction. 
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Table  ?-S 

Tr  an  sac  t i or  throughput  men sur emer  t  s 
Initial  Seer;  a  r  io 

A  V  E  R  A  G  E 


N0_of  GRANULES 

RESPONSE 

TIME 

COMPLETED 

1 

751.914 

1  28 

2 

557.232 

168 

3 

534 . 399 

178 

A 

523 .  OR? 

1  82 

5 

490.297 

195 

7 

506.667 

189 

9 

515.117 

188 

10 

472 . 330 

203 

15 

484 .214 

196 

20 

462 . 678 

208 

30 

472.732 

205 

40 

454 .  189 

212 

50 

441 .537 

218 

75 

430.543 

223 

100 

420.4 1 6 

!  231 

125 

463.255 

208 

150 

460 . 429 

210 

200 

435.748 

222 

250 

504.021 

192 

300 

447.065 

215 

500 

472.088 

204 

750 

570.089 

168 

1000 

546.023 

175 

2500 

815.784 

1  15 

5000 

1054.988 

36 

The  average  resporse  time  and  the  total  number  of 
tr an  sac t ion s  completed  at  time  TMAX  reached  extremums  at 
100  granules.  With  this  number  of  granules,  the  smaller 
transactions  requiring  less  resources  were  able  to  run  to 
completion.  Thus,  a  ’shortest  job  first’  property  was 
observed.  Moreover,  with  finer  granularity  (>?0Q 
granules)  locking  overhead  actually  increased  the  average 
resporse  time.  In  these  cases  the  higher  I/O  locking 


46 


overhead  (753  to  over  6000  time  units)  delayed  the  normal 
processing  of  transactions. 

In  summary,  under  the  initial  scenario  parameter  set¬ 
tings,  the  useful  computer  utilization  increased  as  the 
number  of  granules  increased  then  leveled  off  and  fell. 
Moreover,  the  maximum  utilization  occurred  with  a  rela¬ 
tively  small  number  of  granules  and  that  utilization  was 
within  Mo  of  that  optimum  for  10  granules.  The  conclusion 
can  be  drawn  that  crude  locking  schemes  with  coarse  granu¬ 
larity  were  nearly  optimal.  Since  a  crude  locking  system 
may  be  easier  to  implement  than  a  sophisticated  finer 
granularity  scheme,  it  may  be  preferred. 

For  this  case,  response  time,  and  throughput  were  all 
better  with  a  small  number  of  granules.  Hence,  a  large 
number  of  granules  (such  as  would  be  required  to  lock  disk 
sectors  or  individual  records)  may  be  inappropriate. 

-----  However,  changes  in  the  parameters  and  simulation 
model  do  alter  thes^e  observations.  In  the  next  section* 
the  effects  of  alternate  work' load  parameters  are  reported. 
In.  section  3*3,  the  systems  parameters  are  varied^.  I  r 
section  3.4,  the  effects  of  two  extensions  to  the  model 


ar e  reported . 


3-2«  Effects  °J1  Workload  Parameters 

Changes  in  the  workload  parameters  would  reflect 
charges  in  the  characteristics  of  the  applications  which 
were  running  or'  the  system.  It  has  been  noted  already 
that  the  number  of  transactions  had  little  effect  or  the 
observed  output  parameters.  Other  workload  parameters  did 
make  some  difference  on  the  optimum  granularity.  The 
major  difference  was  due  to  the  lock  placement  assump¬ 
tions.  Other  workload  parameters  tested  included  changes 
in  transaction  sizes,  changes  in  database  sizes  and  the 
addition  of  an  idle  time  period  for  the  transactions. 

3.2 . !•  Placement  of  Locks 

In  the  previous  experiments  the  locks  were  assumed  to 
be  well-placed.  The  other  two  placement  assumptions  were 
also  tested.  In  the  worst  case  assumption,  each  transac¬ 
tion  required  the  maximum  number  of  granules  possible.  In 
the  random  placement  assumption,  the  probability  of 
accessing  any  entity  was  identical  and  independent  of  arv 
previous  entities  accessed. 

Which  model  is  chosen  affects  the  previous  observa¬ 
tions.  If  the  "worst  case"  is  chosen,  the  following 
intuitive  analysis  applies.  In  figure  2-3  it  is  assumed 
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that  all  trap  sactiors  touch  the  same  number  of  entities, 
NE .  The  machine  utilization  measures  would  decrease  as 
the  number  of  locks  for  the  entire  database  increased  from 
one  to  NE.  The  decrease  is  because  each  transaction  would 
require  more  locks  thus  increasing  the  locking  overhead. 
However,  there  would  be  no  additional  parallelism  because 
each  transaction  locked  the  entire  database. 

The  utilization  would  increase,  however,  as  the 
number  of  locks  increased  from  NE  to  the  total  number  of 
entities  in  the  database.  In  this  case,  the  cost  of  the 
locking  overhead  would  remain  constant  while  the  allowed 
concurrency  increased.  The  locking  overhead  would  remain 
constant  since  each  transaction,  could  never  set  more  than 
NE  locks . 

Consequently,  the  optimum  number  of  locks  would  be 
very  dependent  on  the  transaction  sizes  in  the  worst  case 
placement  lock  assumption.  Moreover,  it  would  always 
occur  at  1  granule  or  the  maximum  number  of  granules 
( cor respond  in g  to  ore  lock  per  entity)  if  all  the  transac¬ 
tions  were  the  same  size.  The  effects  of  having  varying 
transaction  sizes  will  be  discussed  below. 

The  simulation  model  was  run  for  each  of  the  three 


placement  assumptions  under  a  wide  variety  of  param^t^r 
settings.  Figures  2-4  and  2-5  diagram  some  of  the 


All  transactions  use 
NE  entities 


Figure  2-3:  Expected  Computer  Utilization 

under  the  Worst  Case  Lock  Place¬ 
ment 


results.  In  figure  2-4,  the  transaction  sizes  were  deter¬ 
mined  by  an  exponential  distribution,  with  a  mean,  value  of 
500  entities  (10%  of  the  database).  In  figure  2-5,  the 
transaction  sizes  were  also  determined  by  an  exponential 
distribution  but  with  a  mean  value  of  5  entities  (0.1%  of 
the  database).  For  these  runs,  the  locks  were  assumed  to 
be  in  main  memory  (no  lock  I/O  required)  and  the  I/O  and 
CPU  time  required  by  the  transactions  were  equal.  These 
conditions  were  chosen  as  the  ores  most  favorable  to  finer 
granularity.  The  other  parameters  were  identical  to  those 
described  in  the  initial  scenario,  with  ore  major  excep¬ 
tion.  In  figures  2-4  and  2-5,  the  random  lock  conflict 
assumption  is  assumed  for  all  three  placement  conditions. 
Under  the  random  lock  conflict  assumption,  the  granules 
associated  with  each  transaction  are  considered  to  be  com¬ 
pletely  uncorrelated.  This  modification,  is  made  primarily 
for  validity  checking.  With  the  same  lock  conflict  assump¬ 
tions,  the  end  points  (1  and  5000  granules)  should  and  did 
result  in  identical  simulation  runs  under  the  three  lock 
placement  assumptions. 

The  top  curves  in  both  figure  2-4  and  2-5  were  con¬ 
sistent  with  the  results  of  the  initial  scenario.  The 
bottom  two  curves  renresent  the  worst  case  and  random 
access  assumptions. 
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For  large  transactions  roquiriri?,  about  10%  of  the 
database  (see  figure  2-4)  a  smaller  number  of  granules  was 
still  to  be  prefered  to  a  lock  tor  each  entity.  For  small 
transactions  requiring  about  0.1%  of  the  database  (see 
figure  2-5)  one  lock  per  entity  produced  the  greatest 
machine  utilization  under  the  worst  case  and  random  place¬ 
ment  assumpt  ion  s  .  However,  even  with  small  tr  an  sac  t  i  or.  s  , 
the  degree  of  improvement  was  small  as  the  granularity 
increased  beyond  a  certain  limit.  For  example,  90%  of  the 
maximum  machine  utilization  was  reached  with  200  locks. 

Next,  the  simulation  was  run  with  mixed  size  transac¬ 
tions  (AMEAN  =  250,  BMFAN  =  5,  ALPH  =  .1)  using  the  best 
case,  the  worst  case  and  random  access  assumptions. 
Intuitively,  this  simulates  a  few  large  transactions  and 
many  small  ones.  As  previously  stated,  under  the  well- 
placed  assumption  a  small  number  of  granules  is  best.  A 
relatively  flat  curve  relating  machine  utilization  and  the 
number  of  locks  is  observed  for  the  worst  case  and  random 
access  assumptions.  Thus,  in  these  two  cases,  the  granu¬ 
larity  of  looks,  whether  coarse  or  fine,  did  rot  greatly 
effect  the  useful  machine  ut i 1 i za t i on .  In  fact,  9B%  of 
the  maximum  utilization  was  achieved  with  both  10  and  2590 
granules.  The  basic  problem  with  fine  granularity  was 
that  the  expense  of  rurring  .just  a  few  large  transactions 
seemed  to  outweigh  the  gain  due  to  the  increased  cor- 
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currency  experienced  by  the  small  transactions. 


3.2.2.  _i°r  Size 

Under  a  uniform  distribution  of  transaction  sizes, 
the  number  of  entities  required  by  a  transaction  was 
determined  by  the  RAD  parameter.  The  simulation  was  run 
under  the  well-placed  lock  assumptions  with  RAD  values  of 
1,  25,  50,  100,  250  and  500  or  a  data  base  containing  5000 
granules.  The  first  case  results  in  an  initial  average 
transaction  size  of  1/1000  th  ( 1 *NTR AN/2 )of  the  database. 
The  last  case  on  the  other  hand,  results  in  an  average 
transaction  size  requiring  one  half  ( 500*NTR AN /2 )  of  the 
entities  in  the  database. 

As  the  needs  of  the  transactions  increased,  maximum 
machine  utilization  and  throughput  were  obtained  with 
fewer  and  fewer  granules.  Minimum  response  time  behaved 
similarly.  The  optimum  1  %  and  5%  intervals  of  useful  I/O 
are  presented  in  figure  2-6.  Note  that  even  for  very 
small  transactions,  95X  of  the  optimum  was  reached  with  as 
few  as  10  granules. 

The  two  other  distributions  of  the  transaction  sizes 
were  also  tested  in  order  to  model  different  transaction 
environments.  With  an  exponential  distribution,  with  the 
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same  mean  value  as  the  uniform  distribution 
( AMEAN=RAD*NTR AN/2  ),  the  results  were  very  similar.  For 
a  small  AMEAN,  say  5  entities,  500  granules  were  optimal. 
Again,  however,  10  granules  produced  useful  machine  utili¬ 
zation  within  5%  of  the  utilization  realized  with  the  500 
granules.  With  an  exponential  distribution  and  an  AMEAN 
value  of  250  entities,  on  the  other  hand,  40  granules  was 
again  optimal.  In  that  case,  the  larger  transactions 
realized  too  much  locking  overhead  with  the  less  coarse 
granularity . 

However,  with  a  hyper-exponential  distribution,  the 
"large"  transactions  (those  determined  by  the  BMEAN  param¬ 
eter)  dominated  the  processing.  Thus  coarse  granularity 
was  again  favored.  For  example,  with  AMEAN,  BMEAN,  and 
ALPH  values  of  5,  250  and  0.1  respectively,  an  NGRAN  of  50 
still  produced  the  maximum  useful  computer  utilization. 
In  this  case,  the  average  transactior  size  was  about  30 
entities.  But  10  percent  of  the  transactions  accessed  on 
the  average  250  entities  and  these  transactions  dictated 
coarse  granularity. 

The  simulation  was  also  run  under  the  random  lock 
placement  assumptions  varying  the  granularity  ard  transac¬ 
tion  sizes.  For  those  experiments,  the  IORATE  and  CPORATE 
were  again  equal  and  the  LIORATE  was  set  to  zero.  The 
other  parameters  were  identical  to  those  described  in  the 
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initial  scenario.  With  an  average  transaction  size  of 
less  than  25  entities,  the  finest  granularity  was  again 
optimal.  When  the  average  transaction  size  was  between  25 
and  50  entities,  the  useful  computer  utilizations  at  1  and 
5000  granules  were  approx imately  equal.  With  an  average 
transaction,  size  greater  than  50  entities  (1£  of  the  data¬ 
base),  ore  granule  was  ootimal. 

3.2.3.  Database  Size 

Simulation  experiments  were  also  run.  with  various 
granularities  or  a  database  of  50000  entities.  The  aver¬ 
age  transaction  size  was  fixed  at  250  entities  and  the 
simulation  was  run.  for  15000  time  units.  The  effects  of 
increasing  the  database  size  was  similar  to  the  effects  of 
decreasing  the  transaction  size.  With  well-placed  locks, 
the  optimal  granularity  occurred  at  500  granules.  In  this 
case,  five  percent  of  the  maximum  utilization  was  realized 
with  20  to  2500  granules.  With  random  lock  placement,  the 
finest  granularity  was  again  optimal. 

3.P.U.  Ldle  Time 

For  some  appl icatior s ,  locks  car  be  held  while  a  user 
or  application  program  pauses  for  some  duratior  (often 
thought  of  as  "head  scratching").  The  simulation  was 
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modified  to  reflect  this  effect  by  holding  all  locks  for 
an  idle  period  of  100  time  units  (say,  for  example,  about 
25  seconds  in  the  in  ter preta tier  mentioned  at  the  begin¬ 
ning  of  this  section).  The  simulation  was  then  run  with 
the  parameter  settings  of  the  initial  scenarios  shown  in 
Tables  2-5  and  2-6. 

The  results  were  remarkably  similar  to  those  in  Table 

2- 2.  The  useful  I/O  curve  had  slightly  more  variation 
than  the  curve  in  figure  2-2  with  a  peak  occuring  at  50 
granules.  Ten  granules  still  produced  useful  I/O  and  CPU 
times  within  5%  of  the  optimum.  Hence  a  small  number  of 
granules  was  still  best  even  with  substantial  pauses  in 
the  transaction  processing. 

3- 2.5.  Workload  Parameter  Summary 

The  lock  placement  assumptions  clearly  had  the  most 
dramatic  impact  or:  the  machine  utilization  as  a  function 
of  locking  granularity.  The  second  most  important  parame¬ 
ter  was  the  size  of  the  transactions  accessing  the  data¬ 
base  . 

Fine  granularity  may  be  best  if  the  following  two 
conditions  were  meet:  1)  almost  all  of  the  transactions 
are  small  and  2)  access  patterns  are  random  with  no 


sequentiality.  Under  these  conditions,  the  greater  the 
number  of  locks.  the  greater  the  machine  utilization. 
However,  the  rate  cf  increase  dropped  dramatically  after  a 
certain  level  of  granularity  was  obtained  (about  200 
granules  in  our  simulation).  Hence  ’’medium’1  granularity 
did  almost  as  well  as  fine  granularity;  coarse  granularity 
was  unaccept abl e  in  these  cases. 

If  too  many  of  the  transactions  access  a  large  por¬ 
tion  of  the  database,  fine  granularity  produces  too  much 
locking  overhead  and  coarse  granularity  was  again  to  be 
preferred . 

Regardless  of  the  transaction  sizes,  if  the  data 
access  patterns  were  primarily  sequential,  coarse  granu¬ 
larity  was  still  the  most  effective. 

3-3.  Effects  of  j.he  System  Parameters 

The  locking  granularity,  determined  by  NGRAN,  has 
been  the  major  system  parameter  studied  so  far.  This 
parameter  is  clearly  the  ore  over  which  the  system  imple¬ 
mentors  have  the  most  control  .  The  effects  of  the  other 
system  parameters  or  the  system  throughput  and  utilization 
are  presented  below.  In  particular,  the  IORATE  and  I00VLP 
parameters  were  varied  in  order  to  ’’balance”  the  1/0  and 
CPU  requirements  of  the  transactions.  Also,  the  L10RATK 
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and  LCPURATE  parameters  were  varied  to  control  the  locking 
overhead.  In  addition,  for  each  parameter,  its  irterac- 

A 

tior  with  the  locking  granularity  is  also  discussed. 

3.3-1.  ±/(±  versiJs  CPU  balance 

The  effects  of  the  ratio  of  the  required  1/0  time  to 
the  required  CPU  time  per  entity  was  in  vest i gated .  The 
CPU  rate  (CP(JRATE)  per  entity  for  a  transaction  was  held 
fixed  at  .05  units/entity.  The  simulation  was  run  with 
I/O  rates  (IORATE)  per  entity  set  at  .01,  .05,  .1,  .2,  and 

.3.  For  each  setting  of  the  1/0  rate,  the  number  of 
granules  (NGRAN)  was  varied  from  1  to  5000.  The  lock  I/O 
rate  per  granule  was  set  equal  to  the  I/O  rate  per  entity 
in  order  to  reflect  the  locks  being  on  the  same  speed  dev¬ 
ice  as  the  data.  Each  simulation,  ran  for  5000  time  units. 
The  other  input  parameters  had  the  values  indicated  in 
Tables  2-5  and  2-6. 

Under  the  well-placed  look  assumption,  the  useful  I/O 
curves  for  each  setting  of  IORATE  were  bell  shaped  and 
heavily  skewed  towards  a  small  rumber  of  granules.  As 
such  they  were  similar  to  the  curves  in  figure  2-2  ar d  are 
not  repeated  here.  The  peak  of  these  curves  occurred  with 
somewhat  finer  granularity  as  the  IORATE  came  closer  to 
the  CPURATE.  With  a  system  balanced  between  I/O  and  CPU 
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requ  i  r  emen  t.s  the  maximum  utilization  of  both  CPU  and  I/O 
resources  was  possible.  However,  even  with  balanced  tran¬ 
sactions,  100  granules  were  sufficient  to  achieve  the  max¬ 
imum  machine  utilization.  With  CPU  bound  transactions 
(CPURATE  >I0HATE)  within  5%  of  the  peaks  was  reached  with 
as  few  as  10  granules.  Varying  the  IORATE  had  little 
effect  on  the  throughput  measurements  (average  response 
time,  and  number  of  transactions  completed)  as  a  function 
of  the  number  of  granules  allowed.  The  useful  CPU  time, 
as  a  function  of  granule  size,  showed  a  similar  distribu¬ 
tion  as  the  useful  I/O.  The  costs  associated  with  locking 
were  again  minimized  with  100  granules. 

Under  the  random  and  worst  case  placement  assumptions 
and  small  transactions,  the  finest  granularity  was  optimal 
regardless  of  the  1/0  to  CPU  balance. 


3-3.2.  Multiple  I/O  Paths 


One  method  of  ’’balancing11  a  system  that  is  I/O  bound 
is  to  increase  the  number  of  I/O  channels  to  main  memory. 
In  the  previous  runs,  the  I00VLP  value  was  ore.  These 
experiments  thus  simulated  a  system  with  ore  I/O  path 
between  main  memory  and  secordary  storage.  In  the  next 
series  of  runs,  this  parameter  was  set  to  three  and  six  to 
simulate,  for  example,  a  database  environment  with  three 
and  six  disk  drives  respectively.  Other  input  parameters 


were  the  same  as  in  Tables  2-5  and  2-6. 

Except  for  greatly  increased  magnitude,  the  output 
parameters  had  a  similar  distribution  as  those  in  Table 
2-7.  The  useful  I/O  time  (IJSEFULIO)  versus  the  granular¬ 
ity,  for  simulation  runs  under  the  well-placed  lock 
assumptions,  are  shown  in  figure  2-7.  Note,  with  10  to 
100  granules,  the  useful  I/O  increased  by  a  factor  of 
about  2.5  for  three  I/O  paths  as  compared  to  the  useful 
I/O  with  one  I/O  path.  (The  best  results  possible  would 
be  increased  useful  I/O  by  a  factor  of  3.)  Moreover,  as 
the  number  of  granules  increased  three  drives  became  less 
and  less  effective.  For  2500  granules,  for  example,  only 
a  1.5  factor  increase  in  useful  1/0  was  realized.  The 
results  for  six  I/O  paths  were  similar.  Ten  to  one  hundred 
granules  tripled  the  increase  in  useful  I/O.  With  25 00 
granules,  the  increase  in  useful  I/O  was  slightly  less 
than,  doubled  . 

In  the  random  and  worst  case  lock  placement  experi¬ 
ments,  the  finest  granularity  was  again,  favored  as  addi¬ 
tional  parallelism  was  made  possible. 

3.3.3.  Lock  1/0  Costs 

In  the  previous  experiments,  the  lock  1/0  rate 
(LI0RATE)  was  equal  to  the  transaction  I/O  rate  (IORATF.). 


In  the  next  series  of  simulation  runs,  only  the  lock  I/O 
rate  and  the  granularity  were  varied.  The  simulation  was 
run  with  other  parameters  as  in  Tables  2-5  and  2-6.  The 
useful  I/O  times  (USEFULIO)  for  the  well-placed  lock 
assumptions  are  shown  in  figure  2-8. 

As  the  lock  I/O  rate  decreased,  a  larger  number  of 
granules  could  be  afforded  before  the  advantages  of  more 
parallelism  were  outweighed  by  the  locking  overhead.  Of 
particular  interest  is  the  situation  where  the  LIORATE  was 
zero.  This  case  is  analogous  to  keeping  all  locks  in 
main  memory.  Even  with  no  lock  I/O  costs,  there  was  a 
very  flat  extremum  for  USEFULIO  between  10  and  200 
granules.  Having  a  granule  correspond  to  fewer  than  25 
database  entities  (number  of  granules  >  200)  resulted  in 
noticeably  poorer  performance.  If  the  interpretation  of 
an  entity  is  a  512  byte  page  (or  a  4096  byte  sector)  a 
database  management  system  should  thus  not  'protect'  less 
than  13,000  (or  100,000)  bytes  of  data  with  one  lock. 

3.3.4.  Lock  C PU  Costs 

The  CPU  costs  for  setting  ore  lock  were  dependent  or 
the  lock  management  algorithms.  To  investigate  the 
effects  of  varying  the  CPU  rate  for  locking  or  the  desired 
granularity,  the  simulation.  was  run  with  CPU  lock 


(LCPURATE)  corts  per  lock  of  .005,  .01,  .025,  .05  ,  .075, 


and  .1.  For  this  series  of  experiments,  the  LI0RATE  was 
set  to  zero  to  simulate  the  effects  of  maintaining  all 
locks  in  main  memory.  Other  parameters  were  as  in  Tables 
2-5  and  2-6. 

Under  the  well-placed  lock  assumption  and  a  small 
number  of  granules,  the  CPU  lock  costs  (L0CKCPU)  were 
approximately  linearly  propor tior.al  to  the  CPU  rate  per 
lock  (LCPURATE).  In  these  cases,  there  were  enough  unused 
CPU  resources  available  for  locking.  For  a  large  number 
of  granules,  however,  the  CPU  lock  costs  increased 
slightly  less  than  linearly  with  LCPURATE.  In  these 
cases,  the  locking  CPU  utilization  interfered  with  normal 
transaction  processing.  For  all  CPU  lock  costs  tested, 
however,  the  minimum  locking  costs  occurred  at  10 
gr an  ules . 

Under  the  well -placed  lock  assumption  the  maximum 
amount  of  useful  CPU  and  I/O  occurred  with  10  to  100 
granules  and  was  about  the  same  regardless  of  the  lock  CPU 
rate.  With  lock  CPU  rates  of  less  than  1  millisecond 
(LCPURATE  =  .005),  the  peak  occurred  at  100  grarules; 
within  1%  of  that  peak  occurred  with  10  to  1000  grarules. 
With  lock  CPU  rates  between  1  and  5  milliseconds  (LCPURATE 
=  .005  to  .03)  the  peak  was  at  50;  but  the  useful  1/0  and 
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CP'J  dropped  off  sharply  with  more  than  200  granules.  With 
higher  lock  CPU  rates,  10  granules  were  optimal  and  at 
most  100  granules  for  the  locking  granularity  were  afford¬ 
able. 

Simulation  experiments  were  also  run  varying  the  lock 
CPU  costs  under  the  random  lock  placement  assumption.  In 
these  experiments  all  transactions  were  small  (AMEAN  =  5, 
ALPH  =  0)  and  the  LIORATE  was  again  set  to  zero.  The  CPU 
and  I/O  rates  for  transaction  processing  were  both  about 
30  mil  1 i second s  per  entity  (IORATE  =  CPURATE  =  .2).  In 
these  experiments,  an  increase  in  lock  CPU  rates  greatly 
affected  the  computer  utilization  at  the  finest  granulari¬ 
ties.  With  a  5  millisecond  lock  cost  (LCPURATE  =  .03), 
the  useful  computer  utilization  was  5%  of  the  utilization 
observed  with  a  2.5  millisecond  lock  overhead  cost 
(LCPURATE  =  .015).  However,  the  finest  granularity  was 
still  optimal  until  a  15  millisecond  per  lock  overhead 
cost  (LCPURATE  =  .1)  was  incurred. 

3-3.5.  System  Parameter  Summary 

Some  of  the  system  parameters  did  suggest  somewhat 
finer  granularity  under  the  well-placed  lock  assumDtiors. 
In  particular,  two  factors  had  some  effect  on  the  optimum 
granularity.  When  the  resources  expended  for  locking  were 
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reduced,  finer  granularity  was  affordable.  With  lock  I/O 
costs  of  zero  and  the  lowest  setting  of  lock  CPU  costs, 
100  locks  was  optimal.  Even  in  these  cases,  though,  too 
fine  a  lock  granularity  was  not  acceptable. 

The  second  factor  which  had  an  effect  on  the  optimum 
granularity  was  the  balance  between  the  CPU  and  I/O 
resource  needs  of  the  transactions.  Under  a  balanced  sys¬ 
tem  load  and  the  well-placed  lock  assumption  50  to  100 
locks  were  again  optimal. 

Under  the  random  and  worst  case  lock  placement 
assumptions,  in  most  cases,  the  lock  cost  parameters 
(LCPURATE,  LIORATE)  did  not  change  the  optimal  granular¬ 
ity.  The  other  system  parameters  had  no  affect  or.  the 
optimum  granularity  under  these  placement  assumptions. 

3.^.  System  E_x tsr_s ions 

In  the  previous  experiments  all  granules  were  assumed 
to  be  the  same  size  and  all  of  the  locks  were  acquired  at 
the  beginning  of  a  transaction.  In  this  section  two 
mod  if ications  to  the  model  are  introduced  to  study  alter¬ 
nate  assumptions.  In  the  first  extension  a  lock  hierarchy 
is  simulated.  In  a  lock  hierarchy,  transactions  of  d  l  f- 
ferent  sizes  lock  different  sized  granules.  In.  the  second 
extension,  a  "claim  as  needed"  locking  strategy  is  simu- 
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lated.  Ir:  that  strategy,  transactions  acquire  locks  as 
they  need  the  corresponding  entities. 

3  - f*. - 1  -  Lock  Hierarchy 

In  many  of  the  previous  experiments  it  is  noted  that 
the  expense  of  locking  a  large  number  of  granules  by  a 
large  transaction  offsets  any  increase  in  parallelism 
realized  by  fine  granularity.  One  way  a  large  transaction 
can  avoid  the  expense  of  locking  many  small  granules  might 
be  to  have  the  large  transactions  lock  large  granules 
while  the  small  transactions  continue  to  use  the  small 
locks  [GRAY76]. 

3  .  ^ .  1  .  1_ .  Thj?  Model  Extensa  on 

In  the  simulation  extension  a  two  level  hierarchy  was 
implemented.  A  transaction,  depending  or  its  size,  either 
requested  a  set  of  small  locks  or  ore  global  lock  which 
covered  the  entire  database. 

With  this  extension,  we  explored  the  interactions 
between  any  two  levels  of  a  more  general  hierarchy.  A 
more  general  hierarchy  could  be  arv  tree-like  graph  struc¬ 
ture.  A  transaction  could  lock  the  root  of  a  subtree  and 
thus  control  access  to  the  parts  of  the  database  covered 
by  any  locks  in  that  subtree.  A1 ter nately ,  the 
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trar:  sac  ti  or.  s  could  mark  the  root  of  the  subtree  to  indi¬ 
cate  that  locking  is  taking  place  at  a  lower  level.  The 
transaction  would  then  treat  each  offspring  of  the  root  as 
its  own  subtree . 

In  the  extended  model,  the  choice  between  the  global 
locks  and  the  small  locks  simulates  the  choice  between  the 
root  of  one  subtree  and  its  direct  descender:  ts .  The  per¬ 
formance  tradeoffs  between  increased  parallelism  and 
increased  locking  overhead  of  a  more  general  hierarchy 
occur  similarly  at  each  node.  Thus,  the  results  of  this 
extension  can  be  applied  to  the  more  general  hierarchy  and 
a  more  complex  tree  structure  need  not  be  simulated. 

The  simulation  was  modified  by  adding  'pending’  and 
’blocked1  queues  for  the  global  lock.  If  a  transaction 
was  "small”,  it  set  the  global  lock  in  shared  mode  and  was 
placed  or:  the  original  pending  queue.  From  that  queue  the 
"small"  transactions  competed  for  the  small  locks  as  in 
the  original  model.  If  the  transaction  was  "large",  the 
global  lock  was  set  for  exclusive  access  and  the  transac¬ 
tion  waits  for  all  active  transactions  to  finish.  With 
the  global  lock  set  for  exclusive  use,  row  transactions, 
regardless  of  size  would  also  wait  in  the  blocked  queue. 
Once  the  large  trarsactior*  was  allowed  to  proceed,  it  went 
directly  to  the  I/O  queue  bypassing  the  small  lock  con¬ 
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Figure  2-9: 


Computer  Utilization  versus 
Threshold  Percentage  in  a 
Lock  Hierarchy. 
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were  assumed.  With  ter  r/ml  1  locks,  the  maximum  machire 
utilization  was  reached  with  thresholds  of  90  ard  100  per¬ 
cent.  A  threshold  of  100%  resulted  ir:  all  trar:  sncti  or  s 
using  the  small  locks,  i.e.  as  if  no  hierarchy  were 
present.  However,  with  1000  small  locks,  for  example,  a 
threshold  of  5  percent  was  optimal.  Charging  the  assump- 
tior:  about  the  placement  of  the  locks  also  made  a  dramatic 
difference. 

Figures  2-10  and  2-11  further  explore  the  effects  of 
the  number  of  small  locks  or:  the  threshold  percentages. 
The  results  in  Figure  2-19  reflect  the  M wel 1-pl need" 
assumption.  Random  access  to  the  database  was  assumed  for 
the  simulation  results  shown  in  figure  2-11. 

Each  of  the  graphs  is  divided  into  three  areas  based 
on  machine  utilization.  The  "optimum”  line  represents  the 
threshold  value,  TP,  at  which  the  maximum  I/O  a nd  CPU 
utilization  was  observed  for  a  giver  number  of  small 
locks.  With  threshold  values  in  area  9,  the  hierarchical 
locking  produced  results  within  ?.%  of  that  maximum  utili¬ 
zation.  In  area  A,  the  utilization  was  less  than  in  area 
B-  In  this  case,  too  few  tr an  sac t i or  s  used  the  global 
lock,  i.e,  the  threshold,  TP,  was  too  high.  In  area  C, 
the  machine  utilization  was  also  less  than  in  area  B.  In 
this  case,  however,  too  many  transactions  used  the  global 
lock,  i.e.  the  threshold,  TP,  was  too  low. 


For  example,  consider  figure  2-10  with  1000  small 
locks.  The  machine  utilization  increased  as  the  threshold 
percentage  was  increased  from  0.1%  to  5%,  but  decreased  as 
the  threshold  increased  from  5%  to  100%.  However,  simula¬ 
tion  runs  with  threshold  percentages  between  1%  and  25% 
produced  within  2%  of  the  machine  utilization  observed 
with  the  optimum  threshold. 

In  figure  2-10,  " we 1 1- pi ac ed "  granules  were  assumed. 
With  more  than  1000  small  locks  the  optimum  value  of  TP 
was  between  1%  and  5%.  With  the  number  of  locks  between 
10  and  100,  TP  values  of  50%  to  100%  were  optimal.  In 
this  granularity  interval,  the  2%  area  included  the  case 
where  all  transactions  used  only  the  small  locks.  The 
overall  maximum  machine  utilization  occurred  in  figure  2- 
10  with  10  locks  and  TP  values  greater  than  50%.  In  these 
cases,  almost  all  of  the  transactions  used  the  small 
locks.  Hence,  the  value  of  a  lock  hierarchy  under  the 
well-placed  locks  assumption  was  very  small. 

However,  in  figure  2-11,  random  lock  placement  was 
assumed.  With  coarse  granularity,  the  optimum  threshold 
occured  at  0.5%.  With  a  higher  threshold,  mere  of  the 
smaller  transactions  would  use  the  small  locks,  ard  conse¬ 
quently  would  lock  a  large  port i or  of  the  database.  As  a 
result,  these  trarsaetiors  would  expend  more  resources  for 
locking  than  if  the  global  lock  were  used  without  sigrifi- 
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Figure  2-10  The  Effects  on  Computer  Utilization  of 
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Threshold  Percentage  with  Well-placed 
Locks  in  a  Lock  Hierarchy 
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cantly  increasing  the  concurrency  allowed. 

In  figure  2-11,  the  differences  in  computer  utiliza¬ 
tion  between  areas  A,  B,  and  C  was  small  for  coarse  granu¬ 
larity.  For  10  granules,  for  example,  no  matter  what 
value  of  TP  was  used,  the  computer  ut i  1  i zatior.  was  within 
3%  of  the  maximum  observed  for  that  granularity.  Simi¬ 
larly,  for  100  granules,  the  computer  utilization  was 
within  15%  of  the  maximum  observed  for  any  value  of  TP. 
Thus  even  with  random  lock  placement,  a  hierarchy  with  a 
small  number  of  small  locks,  at  best,  provided  slight 
improvement  over  a  single  level  locking  system. 

Under  the  random  access  assumptions,  the  overall  max¬ 
imum  machine  utilization  occurred  with  5000  granules  and  a 
TP  of  1%.  The  cross-hatched  area  in  figure  2-11 
represents  those  combinations  of  TP  and  number  of  small 
locks  which  resulted  in  machine  utilization  within  2%  of 
the  overall  maximum.  Hence,  fine  granularity  was  pre¬ 
ferred.  The  lock  hierarchy  effectively  prevented  exces¬ 
sive  locking  overhead  for  large  tr  an  sac  ti  or  s  .  The  coarse 
granularity,  or  the  other  hard,  resulted  ir.  poorer  useful 
machine  utilization  regardless  of  the  TP  setting.  With  10 
granules,  for  example,  the  USFFULIO  was  orly  3/'J  of  the 
maximum  USFFULIO  observed  with  5000  grarules  ar u  a  TP  of 
1%. 


Threshold  perc 


For  fine  granularity,  the  B  areas  in  figures  2-10  and 
2-11  had  considerable  overlap.  For  example,  in  figure  2- 
10,  with  2500  small  locks,  the  2%  of  optimum  interval 
occured  with  a  TP  between  0.5%  and  10%.  In  figure  2-11, 
with  the  same  number  of  small  locks,  the  interval  occurred 
with  TP  values  between  0.5%  and  5%.  Thus,  at  this  granu¬ 
larity,  a  TP  between  0.5%  and  5%  could  safely  be  chosen 
regardless  of  the  randomness  of  the  data  access  patterns. 

In  other  simulation  runs,  as  the  average  transaction 
size  decreased,  the  range  of  acceptable  TP  values  (area  B) 
also  decreased.  With  fine  granularity,  regardless  of  the 
transaction  sizes,  a  threshold  between  1%  and  2%  always 
produced  machine  utilization  within  2%  of  the  maximum. 

With  coarse  granularity,  however,  changes  in  the  size 
of  the  transactions,  created  non-over  lapped  intervals  of 
acceptable  TP  values.  In  other  words,  no  one  value  of  TP 
could  be  chosen  that  would  be  correct  for  vastly  differert 
sized  transactions.  Thus  much  greater  care  must  be 
applied  to  a  hierarchy  with  coarse  granularity.  Further¬ 
more,  a  stable  trap  sac- ti  or  size  environment  must  be 
assumed . 

The  size  of  the  database  was  also  varied.  For  exam¬ 
ple,  the  simulatior  was  run  with  a  database  cc-rsistirg  of 
only  16  entities.  In  this  scenario,  the  possible  irter ac¬ 
tion  of  a  page/rocord  hierarchy  was  examined.  An  entity 
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corre spor.ded  to  one  of  16  records  in  a  page.  The  simula¬ 
tion  was  then  used  to  model  the  effects  of  locking  the 
whole  page  by  the  global  lock,  or  locking  individual 
records  by  the  small  locks.  Some  increase  in  machine 
utilization  was  observed  with  a  threshold  of  50%;  but  the 
increase  over  using  no  hierarchy  at  all  was  less  than  4 % . 
Again  it  appeared  that  a  lock  hierarchy  covering  only  a 
small  number  of  smaller  locks  was  not  worth  implementing. 

The  simulation  was  also  run  with  databases  of  up  to 
100,000  entities.  The  results  were  similar  to  the  results 
produced  with  a  database  of  5,000  entities.  For  example, 
experiments  were  run  where  the  average  transaction  size  of 
most  of  the  transactions  was  just  0.05%  of  a  100,000 
entity  database  and  the  average  size  of  a  few  large  tran¬ 
sactions  is  1%  of  the  database.  In  these  cases,  with  the 
finest  granularity  (100,000  small  locks),  a  threshold  of 
1%  was  still  optimal . 

Other  simulation,  experiments  used  the  worst  case  data 
access  assumption  and  produced  results  very  similar  to 
those  in  figure  2-11. 

3.4.2.  Claim  As  Ne_eded  Lockirg 

There  is  another  difference  between  the  original 
model  and  some  database  concurrency  cor  trol  implements- 


tiors.  In  the  original  model,  a  "preclaim"  strategy  was 
assumed  where  all  of  the  locks  were  acquired  before  any 
transaction  processing  took  place.  In  some  database  sys¬ 
tems,  a  lock  is  not  acquired  until  the  related  entities 
were  actually  needed  by  a  transaction.  These  "claim  as 
needed"  schemes  are  used  either  to  reduce  the  total  time 
locks  are  held  and/or  because  the  locks  to  be  acquired 
depend  on  data  values  of  entities  already  accessed.  In 
these  cases,  some  locks  may  have  to  be  held  while  other 
locks  were  requested,  and  deadlock  can  occur  [C0FF71].  In 
this  section  the  effects  of  a  claim  as  needed  scheme  are 
examined . 

3.^l.2.1_,  The  Model  Extension 

The  simulation  was  modified  by  cycling  each  transac¬ 
tion  through  the  I/O  and  CPU  queues  (see  figure  2-1)  or.ce 
for  each  lock  required.  The  total  I/O  and  CPU  times 
required  for  a  transaction  were  the  same  as  in  the  origi¬ 
nal  model  and  were  equally  distributed  among  each  of  a 
transaction's  cycles. 

Between  each  cycle,  a  transactior  requested  ore  lock. 
If  the  lock  was  granted,  the  transactior  went  or  the 
active  queues.  When  a  transactior  completed  its  last 
cycle  or  the  active  queues,  all  its  locks  were  released  as 
in  the  original  model. 
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If  the  lock  was  denied,  the  requesting  trarsactior 
was  placed  or:  the  blocked  queue.  The  lock  could  be  denied 
due  to  locks  held  by  either  another  active  transaction,  or 
by  a  blocked  transaction.  In  the  latter  case,  the  block¬ 
ing  transaction  was  or:  the  blocked  queue,  and  a  deadlock 
condition  could  exist.  If  deadlock  occurred,  a  victim  was 
picked  for  backout.  The  locks  held  by  the  victim  were 
released,  any  blocked  transactions  were  freed,  and  any 
time  spent  on  the  active  queues  by  the  victim  was  added  to 
a  "lost  time"  total. 

3. 4.2.2.  The  Simulation  Results 

The  modified  simulation  was  run  varying  the  sizes  of 
the  transactions,  changing  the  lock  placement  a ssumpt ion s , 
and  with  and  without  a  lock  hierarchy.  Again  it  was 
assumed  that  there  was  no  I/O  cost  associated  with  locking 
and  that  the  transactions  required  equal  amounts  of  CPU 
and  I/O  resources. 

The  results  of  these  simulation  runs  were  very  simi¬ 
lar  to  the  results  from  the  proclaim  strategy.  In  all 
cases,  a  claim  as  needed  strategy  did  rot  change  the 
granularity  required  for  maximum  machine  utilization. 

For  example,  figure  2-12,  shows  the  results  of  run¬ 
ning  the  simulation  with  no  hierarchy,  well  placed 
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Ir:  the  simulatior  exoerimeris,  the  looking  cost 
observed  ip  the  preclaim  model  was  greater  thar.  the  lock¬ 
ing  cost  observed  i r  the  c  1  a i ri  as  reeded  1  o c k i r. g  model. 
Ir.  the  or  eel  aim  model,  ir  the  uase  of  a  lock  request 
failure,  all  of  th°  locks  had  to  be  requested  acair  .  Ir' 
the  claim  as  r  e e d e ^  model,  i r  the  c*  a s e  of  a  lock  request 
failure  only  the  der:ied  lock  had  to  be  rerequested.  How¬ 
ever  ,  ary  decrease  ir  lock  costs  ir.  the  claim  as  needed 
model  was  more  thar  offset  by  the  lost  time  due  to  res¬ 
tarting  trar:  sactior.s.  Thus,  the  useful  machine  utilize- 
tior  was  greater  under  the  preclaim  model  that  under  the 
claim  as  reeded  strategy.  Mary  other  cases  with  different 
trar sac tior  sizes  and  lock  placement  assume tiers  were  also 


tested  and  produced  similar  results. 

For  example,  figure  .—Ik  c.  o  m  o  a  r  n  c  t  h  &  useful  m  a  v.  ■  h  i  *  e 

u  t  i  1  i  ?  a  t.  i  o  r  b  e  t  w °  e  r  the  t  wo  m  o  d  e  1  s  u  r  d  e  r  t  h  e  a  s  s  u m "  1 1  o  r  s 
that  all  trar  sa  ^  t  i  :  :  w*r  e  small  nr  d  that  esv  h  trar  saltier 

had  random  data  access  natterr  s .  Ir  both  of  these  rurs, 
the  average  trar sac* ior  size  was  0.1%  of  the  database. 
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Figure  2-13 


’Preclaim”  versus  "Clair:  us  Needed" 
with  Random  3’ 1  net-men t  of  Lock.-* 
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i  r. crease  J  .  Thus  ,  the  fAr  er-t  m  r  an  u  1  ar  i  t  v  i  r.  :  .  :rht!V  ".cr? 

bereficial  with  the  claim  as  r  model  thar  with  a  pre- 

claim  model.  hole,  however,  that  the  claim  as  reeded 
scheme  again  produced  less  useful  I/O  and  CDU  utjlizatior 
than  the  proclaim  model. 

However  ,  as  the  average  trar.sactior  size  became  ever 
smaller,  the  last  observatior  did  rot  hold.  With  ar:  aver¬ 
age  transaction  size  of  less  thar:  0.05%  of  the  database, 
random  data  access  patterns,  and  the  finest  granularity, 
the  claim  as  needed  scheme  resulted  in  greater  useful 
machine  utilization.  Under  these  conditions,  the  claim  as 
needed  strategy  allowed  the  greatest  concurrency  since 
locks  were  held  for  a  shorter  period  of  time.  In  contrast 
to  other  runs,  very  few  tr  an  sac  t  i  or.  s  had  to  be  backed  out 
and  the  cost  of  rerunning  such  small  transactions  was 
in  si gn i f icant . 

The  modified  simulation  was  also  rur  with  a  lock 
hierarchy  ar.d  various  threshold  percentage  values.  A 
similarity  ir  the  shapes  of  the  curves  betweer  the  cre¬ 
el  aim  and  claim  as  reeded  s  t r  o  t  e  i  e  s  was  also  observed. 
Under  the  random  access  a ssumrt i : r s  ,  for  example,  the  max¬ 
imum  machine  utilizatior  was  again  reached  with  the  finest 
granular i ty  ard  a  threshold  value  of  1  to  9  percent . 


A  locking  hi  erar*.  k  v  should  be  implemented  wner  the 
small  locks  are  of  a  fir.e  gr  an  ul  nr  i  t  v ;  a  low  threshold  was 
used  to  separate  the  largo  ar:d  snail  trar  sac  tier  s ;  and 
random  data  access  oatterr s  were  anticipated.  Under  these 
assumptior  s  the  increase  in  machine  utilizatior  over  a 
single  level  locking  scheme  was  significant.  Furthermoret 
a  threshold  of  about  one  percent  produced  the  best  results 
independent  of  the  granule  placement  or  transaction  size 
assumpt ions. 

With  coarse  granularity,  or  the  other  hand,  a  locking 
hierarchy  was  not  beneficial.  The  benefits  of  such  a 
hierarchy  were  not  significant  and  were  only  realized  in 
certain  cases.  Another  problem  with  the  coarse 
granular i ty/locking  hierarchy  model  was  that  the  optimum 
value  for  the  threshold  percentage  was  extremely  sensitive 
to  the  placement  of  the  locks  with  respect  to  the  transac¬ 
tions  . 

The  acquisition  of  locks  throughout  the  processing  of 
a  trar- sootier  did  ret  si  gr  i  f  i  car  1 1  v  char  th«  other  cor  - 
c 1 u  s i o  r  s .  However,  several  c  h  s  e  r  v  a  t i  r  a  were  made. 
Deadlock  detect: or  ar  d  r^soluticr  ar.:>°  ared  to  be  ger  erallv 
more  expensive  than  the  release  ar d  rerequert  used  ir  the 
preclaim  strategy.  Thus,  wher:  locks  were  known  at  the 


g  n 

start  of  a  t  r  a*'  sac  t  i  c  r  .  orc\  1  a  1  ■■  nl  gor  i 4  r.m  i  •*  ar”-;'*: 

A  .  'v;-’ 

The  activity  and  effects  of  a  locking  ae^hir  !  r,a  were 
simulated  to  studv  the  tradeoffs  between  increased  paral¬ 
lelism  of  cor  currently  running  tr  ar:  sac  tier  s  and  increased 
overhead  caused  by  sophisticated  ar:d  coapl  ex  lockirr 
mechanisms.  The  conclusions  of  the  study  are  first 
applied  to  physical  granules.  The  application  of  these 
results  to  predicate  locking  is  then  discussed. 

^•1* 

Under  the  assumpt i or  s  mentioned  in  the  description  of 
the  model,  in  many  cases  a  small  number  of  granules  is 
sufficient  to  allow  enough  parallelism  for  efficient 
machine  utilization.  Furthermore,  a  large  number  of 
granules,  correspond  in g  to  locking  a  page  or  record  is 
ofter.  extremely  costly. 

These  basic  corclusiors  are  due  to  the  fo  1  1  c \:i r  ~ 
observatior  s  .  For  large  transactions,  fire  grar  ul  ?.r  i  t  v 
becomes  too  expensive.  A  transaction  which  accesses  half 
of  the  database,  for  example,  would  spend  c.  :  r  si  der  ab  1  e 
resources  locking  each  page.  Yet.  little  gair  in  Parallel¬ 
ism  would  he  realized  since  other  transactions  would  have 
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a  stror  g  rr:h  ahi!  it  v  u  f  cor f 1 i v  t: r g  wild  thrt  large  trar - 
sac-tier.  A  small  tr^r  met:  -r  accesses  or.  lv  ore 

page,  or  thrt  other  hard,  must  lc^k  a  much  larger  p,rar.ul  e. 
The  result  art  loss  in  parallelism  is  minimized  because  the 
small  trar section  would  orl  v  hold  the  lock  for  a  short 
period  of  time.  The  probability  of  corflict  and  the 
length  of  any  waiting  period  would  rot  be  1  are e  due  to 
that  short  period  of  time  that  the  lock  is  held. 

However,  there  are  corditiors  where  these  observa¬ 
tions  do  rot  hold.  Details  of  which  cord  itior.s  support 
which  level  of  granular i ty  are  presented  below. 

If  equal  sized  lockable  granules  are  assumed,  a  small 
number  of  granules  (10  to  100)  are  sufficient  under'  ary  of 
the  following  corditiors: 

1)  The  locks  are  well  placed  with  respect  to  the  running 
tr  ar:  sac t ior  s  . 

?)  The  number  of  entities  required  by  trarsactiors  vary 

in  size  and  include  at  least  some  trarsactiors  that 

r  e  q  u  i  r  e  access  to  a  large  r.  u  m  h  e  r  c  f  er  titles. 

3  )  Some  pc  r  t i o  ?  of  the  1  : c  k i r  g  s  c  h ^  m o  ir  vclvcc  extra  I / 0 

for  leoki'r  proper  t  i  or  al  to  tr-.e  rumb^r  of  leeks. 
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However  ,  each  .  f  t  he  fo-1 1  <  '  •-  f'i>t  rs  s'.ir.n  ,.rts  rome- 

what  finer  gran ul nr i tv  : 

1)  All  of  the  trnrmctior  s  ire  extremelv  small  and 
access  less  than  1%  of  the  database. 

?.)  The  length  of  time  that  locks  are  held  is  extremely 
long  and  rot  proportional  to  the  size  of  the  trarsac - 
tier,  as  was  the  case  with  the  "idle  time"  experi- 
men  ts  . 

31  The  locking  costs  are  reduced,  for  examole,  by  keen¬ 
ing  all  locks  in  core. 

4)  A  balance  exists  between  the  1/0  resources  and  CPU 
resources  required  for  processing  a  transaction  . 

If  all  of  the  following  cor'ditiors  are  met,  the 

finest  granularity  should  be  used: 

1)  All  of  the  transactions  are  small. 

2)  The  looking  costs  are  reduced  by,  for  example,  keep¬ 
ing  all  locks  ir.  care. 

31  Random  access  patterrs  (or  worsel  are  exhibited  by 
the  trar.  sac  tier  s  . 
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However,  if  cor d it i or  1  is  violated,  a  1  k  hierarchy 
must  he  used  if  the  fire  granularity  i  r>  still  to  he  sup¬ 
ported  . 

The  overall  corclusior  is  thus  that  the  cptirnufn  lock¬ 
ing  granularity  is  somewhat  applicatior  dependent.  In 
many  cases,  coarse  granularity,  such  as  file  or  relatior' 
locking,  with  a  proclaim  strategy  is  to  be  preferred.  In 
other  cases,  somewhat  finer  granularity,  such  as  area  or 
extent  locking  is  best.  In  still  other  cases,  the  finest 
granularity  such  as  page  or  record  locking  is  required. 

4.2.  Locking 

Four  results  from  the  simulation  support  the  poten¬ 
tial  viability  of  predicate  locking.  Firstly,  with  predi¬ 
cate  locking  only  a  small  number  of  locks  must  be  main¬ 
tained  and  car:  probably  be  maintained  in  main  memory.  The 
number  of  locks  is  proportional  to  the  number  of  active 
trar.sactior  s  and  not  to  the  size  of  the  database. 

Secondly,  while  predicate  lockirg  may  require  more 
CPU  time  per  grarule  thar  Physical  lockirg,  the  simulaticr 
results  irdicate  that,  for  coarse  grarularitv,  some 
increases  in  locking  overhead  are  affordable  ar d  do  rot 
sigrificartly  ir  ter  fere  with  t r  a  r  s a  c  4  i c  r  process; r  g  . 


Thirdly,  the  par  erne  tor  u  r;  had  c  cr  5  i  d^r  abl  ■"•*  ofhn  t 
or  the  dosirei  rubber  of  q  r  a  r  ulor  was  the  rubber  of  er.  ti¬ 
tles  •touched*  tv  the  Iror  t:rr  As  the  trarsactior 

size  decreased,  the  desired  rubber  of  granules  increased. 
Note,  ir  predicate  locking  schemes,  the  portior  of  the 
database  locked  is  determir.ed  by  the  trar:  sac  tior  ,  ard  rot 
a  pr  esoec  i  f  ied  t*r  a  r :  ul  ar  i  t  v  ,  effectively  mimicking  the 
above  variable  nr  ar.  ul  ar  i  ty  * 

Finally,  the  results  of  the  lock  hierarchy  simulaticr 
mi^ht  indicate  that  a  simple  predicate  locking  scheme 
mip.ht  be  sufficient.  Ir:  ore  such  scheme,  two  types  of 
locks  could  be  supported.  First  an  entire  relatior, 
record  type  or  file  could  be  locked.  The  small  locks 
would  be  based  or  a  simple  unique  key-value  pair.  The 
predicate  locking  scheme  could  easily  check  whether  a 
key-value  pair  conflicted  with  either  ar.  entire  relation 
lock  or  other  key-value  pairs.  The  lock  hierarchy  simula¬ 
tion  results  indicate  that  orlv  a  small  number  of  key  - 
value  pairs  would  have  tc  be  mair  tair.ed  before  the  larger 
style  lock  should  be  applied.  furthermore ,  the  simulaticr 
results  indicated  that  subsettir r  the  trar sac  tiers  tv  less 
dense  attributes  (ores  with  crly  a  hardful  of  differert 
values)  would  rot  be  bereficial  ir  a  lock  hierarchy. 
Thus,  ir  these  cases,  keeoirq  the  predicate  locking 
mechanism  quite  simple  would  be  justified. 
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However,  stub  a  simple  predic'te  1  -  a-  k  ir  m  m  cc  bar  :  am  is 
r:  o  t  very  d  1  f  f  r  r.  t  f's^c  ■ :  a  s  i  • ;  n  1  e  :  h  v  s  i  c  a  1  1  cc  k  hi  er  a  r  <.  h  v  . 
For  example.  locking  n  1  •:  n,  i  ^  ^ ;  relatior  may  ir  seme  imnle- 
mer;  la  tiers  bo  identical  to  lock  ire  a  physical  file  or 
area.  At  the  firest  grnr  ul  nr  i  ty ,  a  predicate  lock  of  a 
unique  key-value  pair  identifies  ore  record.  A  physical 
lock,  or  the  other  hard,  would  uniquely  identify  the  same 
record  by  a  physical  address.  Thus,  in  terms  of  parallel¬ 
ism  and  operation,  a  simplified  predicate  locking  scheme 
is  identical  to  a  physical  locking  scheme.  The  physical 
locking  scheme,  however,  may  be  easier  to  implement. 
Moreover,  the  physical  address  for  a  record  might  take  up 
less  space  in  a  lock  table  than  a  predicate  lock  for  the 
same  record  . 


Another  problem  exists  with  predicate  locking.  In 
some  aopl icatior s ,  a  secondary  key  or  index  is  used  to 
access  a  given  record  type.  Under  the  simple  predicate 
locking  hierarchy  described  above  either  all  access  via  a 
primary  key  would  have  to  wait  for  the  seccrdarv  index 
appl  icatior  to  complete;  c r  the  record  would  have  to  be 
read,  the  key  value  obtaired,  nr  d  ther  a  lock  requested. 
When  the  lock  is  grnr  t  e  d  t  r.  °  r  **  c  o  r  d  w  ■  u  1  d  h  a  ve  Iz  be 
reread.  With  physical  1 c  ^  k s .  c  r  the  ether  hard,  the  phy¬ 
sical  record  address  wcul  i  h?  ur  ique. 


t 
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Ir  smirnary,  th^r  ,  whil<‘  predicate  3  ■:  k i  r  '*  ’nay  be 
viable,  it  dees  not  s  o  e  m  to  ho  worth  the  e  x  t  r  *  ;»  i  ,r,  o  1  ern  er  t  a  - 
tier  ar ri  1  cc V; i r : ri  overhead,  b e^;  o u so  it  car  c r  1  y  b e  a r n  1  i c  : 
wher  specific  sets  of  the  database  need  to  be  1  •;  c  k  i  r.  r  . 


CHAPTER  3 


DISTRIBUTED  DATABASE  SYSTEMS 

i  •  INTRODUCTION 

In  the  previous  chapter,  simulation  models  were  used 
to  investigate  the  performance  issues  of  concurrency  con¬ 
trol  in  a  centralized  database.  In  this  chapter,  those 
simulation  models  are  extended  to  study  the  performance 
issues  of  concurrency  control  in  a  distributed  database. 

!*!•  Distributed  Databases 

In  a  distributed  database,  the  data  is  stored  at  mul¬ 
tiple  computer  sites  connected  by  some  tyoe  of  computer 
network.  In  this  environment,  a  transaction  originates  at 
one  of  the  computer  sites  and  potentially  accesses  data  at 
other  (or  remote)  sites  as  well  as  at  the  originating 
site. 

The  benefits  of  a  distributed  database  include  the 
ability  to  share  and  access  c  eo  gr  a  oh  i  c  a  1 1  v  distant  data, 
to  exercise  some  local  ccrtrcl  ever  subsets  of  the  data¬ 
base,  to  provide  mcdular  growth  3rd  resiliercv  to  the 
database,  ard  to  increase  the  ootertial  parallelism 
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allowed  in  accessing  the  database. 

A*?*  Distributed  Database  Concurrency  Control 

The  distributed  concurrency  control  mechanism  must 
guarantee  the  same  type  of  consistency  which  was  needed  ir> 
the  centralized  database.  However,  the  performance  issues 
in  a  distributed  database  are  different  than  in  a  central¬ 
ized  database.  This  difference  is  due  to  the  following 
f  actors : 

1)  More  parallelism  is  possible  because  multiple  sites 
can  simultaneously  process  transactions.  In  the  cen¬ 
tralized  model,  at  most  two  servers,  the  I/O  and  CP'J 
processors,  could  be  kept  busy.  In  an  N  site  system, 
there  are  2*N  servers  which  can  be  simultaneously 
processing  transactions. 

2)  The  overhead  associated  with  distributed  concurrency 
control  will  be  higher  than  the  overhead  required  in 
a  centralized  database.  The  additional  overhead  is 
due  to  the  costs  required  to  set  locks  at  remote 
sites  and/or  the  costs  which  may  be  required  to 
resolve  deaolcck  between  transactions  at  different 
sites.  The  remote  locking  overhead  is  due  to  the 
network  delays  involved  with  ser.  dire;  and  receiving 
lock  messages.  The  deadlock  resolutior  overhead 


includes  the  computer  resources  required  to  detect 
deadlock  and  to  roll  back  certain  transactions. 

The  simulation  model  for  the  centralized  database 
concurrency  control  was  extended  to  investigate  the 
trade-offs  between  the  increased  parallelism  and  increased 
overheads  of  a  distributed  database.  The  major  areas  of 
study  include  the  effects  of  varying  the  locking  granular¬ 
ity,  varying  the  percentage  of  transactions  requiring 
non-local  or  remote  resources  and  varying  the  throughput 
and  bandwidth  of  the  network. 

In  the  next  section,  the  extensions  of  the  simulation 
model  which  apply  to  all  distributed  concurrency  control 
algorithms  are  discussed.  In  section  3,  four  different 
concurrency  cottrol  algorithms  and  their  associated  simu¬ 
lation  extensions  are  discussed.  In  section  4,  the  simu¬ 
lation  results  for  each  of  the  four  algorithms  are 
reported.  In  the  final  section,  the  major  conclusions  are 
stated  . 

2  .  MODEL  EXTENSIONS 

In  this  section  the  model  extersicrs  are  described. 
First,  the  network  mo  lei  is  reviewed.  t’ext  the  actio:  s  at 
each  of  the  nodes  or  network  sites  is  discussed.  Fir  ally, 
the  input  and  output  parameters  of  the  model  are  dis- 
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cussed.  Throughout  this  section,  only  the  processing  of 
transactions  v; i  1 1  be  considered.  In  the  next  section, 
four  concurrency  cortrol  algorithms  will  be  integrated 
into  the  model . 


?•!*  Network  Model 

The  network  is  considered  to  be  a  collection  of  com¬ 
puter  sites  called  nodes,  all  corrected  by  a  "logical  net¬ 
work  manager"  as  shown  in  figure  3-1.  This  manager  could 
represent  a  specific  star  like  network,  or  a  more  general 
rode  to  node  network  like  the  ARpAN£T  [KLEI76].  In  either 
case  it  is  assumed  that  the  time  to  send  a  message  between 
any  pair  of  nodes  is  the  same. 

Each  Node  contains  a  message-in  and  a  message-out 
queue.  Messages  are  taken  from  the  message-out  queue  and 
given  to  the  Network  Manager  together  with  a  destination 
and  a  message  length.  When  a  message  has  received  the 
needed  amount  of  network  service,  it  is  placed  or  the  des¬ 
tination  message-in  queue. 

Both  a  speed  and  a  bandwidth  are  associated  with  the 
Network  Manager.  The  network  soeed  is  represented  by  the 
minimum  time  a  message  of  any  tvne  must  soer d  in  the  net¬ 
work  where  time  is  measured  in  the  time  units  of  the  simu¬ 
lation.  The  bandwidth  is  represented  by  the  maximum 


Network  manager 
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NODE  0 


NODE  N 


Figure  3-1:  Network  Model 
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number  of  messages  which  can  be  serviced  in  ore  of  those 
time  units. 

The  flow  of  a  message  in  the  Network  Manager  can  be 
described  as  follows: 

1)  When  a  message  enters  the  network  manager,  the  time 
remaining  for  that  message  is  initialized  to  the  mes¬ 
sage  length  in  the  time  units  of  the  simulation.  The 
message  length  can  vary  depending  on  whether  or  not 
data  is  being  sent  but  is  at  least  equal  to  the 
minimum  length  mentioned  above.  More  details  on  this 
length  are  in  section  2.3. 

2)  If  MESSBDWH  is  the  bandwidth  of  the  Network  Manager, 
the  times  remaining  of  the  first  MESSBDWH  messages  in 
the  Network  queue  are  reduced  by  one  time  unit. 

3)  If  the  time  remaining  for  any  message  is  zero,  it  is 
delivered  to  the  message-in  queue  of  the  destination 
node . 

In  several  of  the  corcurrency  control  schemes,  a  site 
can  send  messages  to  itself.  In  these  cases,  r o  r etwork 
resources  are  consumed  cr  retwork  delay  realized,  since 
the  message  is  taken  directly  off  of  the  message-cut  queue 
and  placed  or:  the  messag^-ir.  queue.  However, 
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sage  costs  (CPU  time  spent  by  a  node  handling  messages) 
are  included  for  these  sel f-direc ted  messages* 

2.2.  Site  Model 

Each  site  or  rode  in  the  model  is  very  similar  to  the 
centralized  model  presented  in  Chapter  2.  However, 
several  new  queues  and  procedures  were  added  to  process 
distributed  transactions.  The  new  model  is  shown  in  fig¬ 
ure  3-2.  Again  transactions  are  cycled  around  a  closed 
loop  model  and  initially  arrive  ore  time  unit  apart  on  the 
pending  queue . 

There  are  three  possible  types  of  tr an  sac ti or s  in  the 
model.  First,  there  are  local  transactions  which  are 
identical  to  the  transactions  in  Chapter  2.  Secondly, 
there  are  MASTER  transactions  which  require  access  to 
parts  of  the  database  at  randomly  selected  other  nodes . 
The  MASTER  transactions  initiate  a  fixed  number  of  SLAVE 
transactions  at  those  other  rodes  via  messages. 

The  transactiors  go  through  the  following  steps:  1)  leave 
the  pending  queue,  2)  I/O  orocessirg,  3)  CPU  orocossirg, 
U)  data  transmission,  5)  local  processing  com ole tic:  ,  ar d 
6)  distributed  processing  synchrcr i za tior  . 

1)  When,  a  trar.sactior  leaves  the  per  ding  queue  it  is 
placed  or  the  I/O  queue.  If  the  trar.sactior  is  a 


MASTER,  it  sends  SLAVE  create  messages  to  the 
appropriate  nodes. 

The  I/O. server  is  multiplexed  amor^  the  transactions 
or:  the  I/O  queue.  When  a  transaction  has  received 
its  share  of  I/O  resources,  it  is  placed  on  the  CPU 
queue  . 

The  CPU  server  is  multiplexed  amor,  f*  the  transactions 
in  the  CPU  queue.  When  a  transaction  has  received 
its  share  of  CPU  resources,  its  next  action  depends 
or:  whether  or  not  the  transaction  is  local. 

Local  transactions  are  considered  complete  at  this 
point  and  recycled  to  the  pending  queue.  Non-local 
transactions  (both  SLAVES  and  MASTERS)  are  placed  on 
the  data  tr arsmissior:  queues.  If  any  data  is  to  be 
trar smithed,  a  data  transmission  message  is  sent. 
This  transmission  message  is  in  fact  addressed  back 
to  the  sending  transaction.  Thus  the  data  trar.smis- 
sior  is  comolete  when  this  message  is  delivered  back 
to  the  originating  site. 

Wher  the  data  trar  omission  message  has  beer.  received 
(or  if  r.c  data  was  to  be  trar  smithed),  the  r  or -local 
trar  saltier  ore  coeds  tc  the  Network  dcre  queue.  At 
this  time,  SLAVE  transactors  send  a  SLAVE  complete 


message  back  to  the  MASTER  trar sac  tier  . 

6)  Depending  or.  the  concurrency  cor  tro]  strategy, 

SLAVE  either  waits  on  the  Network  done  queue  or  is 
simply  released.  The  release  of  a  slave  is  discussed 
in  more  detail  in  section  3.  The  MASTER  trarsactior 
waits  or:  the  Network  dope  queue  until  it  has  received 
"slave  complete"  messages  from  all  its  slaves,  At 
that  point,  the  trarsactior  is  recycled  back  to  the 
pending  queue. 

Three  tyDes  of  messages  are  common  to  all  of  the  cor - 
currency  control  algorithms.  The  actions  caused  by  these 
messages  are  described  below. 

1)  When  a  "SLAVE  create"  message  is  received,  a  transac¬ 
tion  identical  to  the  MASTER  tr ar:  sac  t  i  or  t  or  1  y 
flagged  as  a  SLAVE  is  added  to  the  per  ling  queue. 

2)  When  a  "data  transmission  done”  message  is  received, 
the  waiting  MASTER  or  SLAVE  trarsactior  is  retired. 

3)  When  a  "SLAVE  complete"  message  is  re:  e \  o  :  ,  t:.*'1 

ccrr e sper d  ir g  MASTER  trar.si.  t;  rr  s  cr  the  N*?tw  ic  r  <-• 
queue  is  rotified.  If  the  VA  '7E-  trar  rattier  ;  ■'  ret 
completed,  the  message  is  returned  t *  the  m^sago-ir 
queue  until  the  MASTER  trar  tier  coarl . 


Several  simplifying  assumptions  should  be  noted  about 
the  model.  First,  all  of  the  SLAVEs  are  identical  to  the 
originating  MASTER  in  terms  of  the  proportion  of  database 
accessed  and  whether  or  not  data  is  to  be  transferred.  In 
distributed  database  appl icat ions ,  the  actual  characteris¬ 
tics  of  the  SLAVES  could  be  quite  different  from  the  MAS¬ 
TER  and  from  each  other.  Second,  the  only  synchror ization 
between  the  SLAVEs  and  their  MASTER  transaction  occurs  at 
the  beginning  and  end  of  the  transaction.  Some  applica¬ 
tions  would  require  additional  synchronizations  or  the 
data  being  transmitted  [WONG77,  F.PST78  ]  • 

Also  rote  that  a  transaction  is  or:  each  of  the  I/O, 
CPU  and  data  transmission,  queues  once  in  the  indicated 
serial  order.  The  total  processing  required  is  the  same 
as  if  the  transaction  cyclically  accessed  the  I/O,  CPU  and 
data  transmission  queues. 


2. 3.  Model  Parameters 

The  input  parameters  car  be  divided  into  the  parame¬ 
ters  that  characterize  the  workload,  the  svstem  parameters 
that  characterize  the  irdividual  'odes,  ard  the  parameters 
that  characterize  the  network.  Tae  workload  parameters 
deter- ir e  the  database  ard  thn  trar.  sac  tier  s  that  are  rur 
agairrt  that  database.  As  ir  Chapter  2,  the  system  par  am- 


eters  determine  the  computer  and  database  mnnageme rt  sys¬ 
tem  characteristics.  The  network  parameters  include  the 
minimum  time  required  for  messages,  the  network  bandwidth 
and  the  CPU  and  I/O  resources  required  for  processing  mes¬ 
sages  at  each  site. 

The  output  measurements  include  the  overall  CP'J  arc 
I/O  resource  utilizations  for  transactions ,  messages  and 
concurrency  control  as  well  as  network  measurements. 

These  parameters,  in  most  cases,  have  the  same 
in  ter pretatior  as  in  Chapter  2.  All  of  the  parameters  are 
described  in  detail  below. 

2.3*2'  Workload  Parameters 

The  workload  parameters  describe  the  transact icrs  ard 
the  portion  of  the  database  at  each  node.  Table  <-i  sum¬ 
marizes  the  workload  parameters. 

The  first  five  parameters  are  identical  to  the  param¬ 
eters  discussed  in  Chanter  2.  For  almost  al-  t  h*a 
experiments  reported  in  this  chanter  orly  a  few  s^ttir  ’ 
of  those  parameters  are  used.  The  effects  :f  v  *rvi- 
those  parameters  would  be  similar  tc  the  effects  ; 

ir.  Chanter  2. 

Ir.  particular,  NTR-VJ  was  set  tc  10  simulative  10 
transactions  rurr  ir.  g  at  each  node.  The  DPTI/F.  at  each 


Table  3-1 

Workload  Parameter s 
Parameter  Description 

Local  Parameters 

NTRAN  Number  of  transactions  running  at  each  node 

DBSIZE  Size  of  the  portion  of  a  database  at  a  f^iven  node 
AMEAN  Low-mean  of  exponential  distribution 
for  transaction  size 

BMEAN  Hi^h-mear.  of  exponential  distribution 
for  transaction  size 

ALPH  Cut  point  for  Hyper-exponential  distribution 
for  transaction  size 
LKPLMT  Lock  Placement  assumption 

Distributed  Parameters 

PREDIST  Percentage  of  transactions  which  are  non-local 
PRETRAN  Percentage  of  distributed  transactions 
which  transfer  data 

PREDATT  Percentage  of  data  transferred  by 
those  distributed  transactions 
NSLAVES  Number  of  SLAVES  for  a  distributed 
transaction 


node  was  set  to  10,000,  resulting  in  a  total  database  size 
of  10,000  times  the  number  of  nodes  in  the  network. 

Two  classes  of  transactions  are  modeled.  With  class 
one  transactions f  the  transaction  sizes  vary  considerably 
and  the  locks  are  assumed  to  be  well-placed  with  respect 
to  the  accessir ?  transactions.  For  these  trarsactiors 
A^EAN  is  5,  P’-'EAN  is  230  ard  the  *\LPH  parameter  was  set  to 
.1.  This  class  of  trarsactiors  simulates  a  workload  where 
most  (90*)  cf  the  trarsactiors  are  small  (they  access  0.^5 
per cert  cf  the  database)  ard  a  few  cf  the  trarsactiors  are 


lar . 
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With  class  two  trar.sactior  s  *  all  tr  an  sac  t  i  ci  s  arc 

small  and  the  placement  of  the  locks  is  assumed  to  be  ran¬ 

dom  with  respect  to  the  accessing  transactions. 

The  remaining  parameters  deal  with  the  non-local 
transactions  and  are  the  ones  of  most  interest  ir  this 
chapter.  The  proportion  of  transactions  which  are  MAS¬ 
TERS,  the  PREDIST  parameter,  determir.es  the  number  of 
t  r  an  sac  t  i  or1  s  at  each  node  which  require  processirg  at  som^ 
other  site.  Experiments  were  run  with  PREDIST  setti rrs  of 
0,  10,  25,  50,  75  and  100  percent. 

The  number  of  SLAVES  required  by  a  MASTER  are  inter- 

mined  by  the  NSLAVES  parameter.  The  origiral  r. umber  of 

database  entities  required  by  the  MASTER  is  evenly  distri¬ 
buted  among  the  SLAVES  and  the  MASTER.  Thus,  if  the  MAS¬ 
TER  originally  requires  E  of  the  database  er*M  toes,  at 
each  site  where  the  transaction  was  active, 
E/(NS LAVES  +  1),  entities  are  actually  accessed. 

The  amour t  cf  data  to  be  transferred  is  do tormirod  by 
the  FRFTEAN  ar  d  PREDATT  parameters.  The  P  R  "  7 h  run  ■■■voter 
determiros  the  r  umber  of  distributed  Lmr  n-.t:  :  ■■  i 
trarsfer  ar  v  data  at  all.  The  PRTr  ATT  r  ar  ‘ --r  -v-t^r- 
mir.es  hew  mar  y  of  a  tr  ar  sac  t  i  or  f  s  er  titles  will  have  t:  r-? 
transferred.  The  r  umber  of  ertities  trarsf^rre:  :eter- 
mires  the  1 e  r  r t  h  c  f  a  data  trarsfer  message  a r  1  h  e  r  c  e 
determines  hew  long  a  trarsacticr  soar  da  or  t  he  h'ntw  .  r  / 


wait  queue. 


In  summary,  the  database  consists  of  a  collection  of 
entities  at  each  node.  Each  transaction  ’’touches1'  or 
accesses  a  certain  number  of  those  entities.  Some  of 
those  transactions  require  access  to  entities  at  remote 
nodes.  Furthermore,  some  of  those  transactions  will  have 
to  transfer  data  between  nodes. 

2,3.2.  System  Parameters 

The  system  parameters  describe  the  computer  system  or 
database  system  at  each  node  and  are  very  similar  to  the 
system  parameters  of  the  centralized  database  model 
described  in  Chapter  2.  The  system  parameters  are  summar¬ 
ized  in  Table  3-2. 

The  NGR.AN  oarameter  is  the  number  of  lockable 
granules  at  each  node  of  the  distributed  database  and  is 
identical  to  the  'JGRAN  oarameter  of  Chapter  2.  The  oaram- 

Table  3-2  System  Parameters 
r ejscr  i  r M  or 

number  of  lockable  urits  of  ere  rode 
of  the  database 

C P'J  time  to  process  ere  ertitv 
I/O  time  to  process  ere  entity 
CPU  time  tc  process  ore  leek 
I/O  time  to  process  ore  leek 


Parameter 

NCR  A\f 

CPUS  ATE 
I  o  p  »  t  E 
LCP IRATE 
LI  OR. A  7E 


eter  was  varied  from  1,  repr  esen  t  i  r:  r  or o  1o<Vk  at  eru  h 
node,  up  to  DBSIZE,  repr  eser.  t  i  r:  i\  ore  lovk  per  entity  ir 

the  database. 

The  CPURATE  and  IORATE  determine  the  cost  to  process 
ore  entity  in  the  datahase  and  are  also  icier. tical  to  the 
parameter  in  the  centralized  database  model.  For  these 
experiments,  the  CPURATE  and  TORATE  were  both  equal  to  ' 
time  unit.  This  scenario  simulates  a  system  with  a  bal¬ 
anced  load  between  the  CPU  and  I/O  requirements.  Also 
under  this  scenario,  ore  time  unit  of  the  simulation  car 
be  thought  of  as  the  time  required  for  ore  I/O  operatior  , 
i.e.,  about  30  milliseconds. 

The  LCPURATE  and  LIORATE  parameters,  the  costs  to  set 
and  release  ore  lock,  are  also  identical  to  the  parameters 
in  the  centralized  database  model.  For  these  oxror imorts, 
the  lock  CPU  rate  was  ore  tenth  the  entity  Cpu  rate, 

0.1.  Under  the  scenario  mer.tiored  above,  this  miqht 
renresert  3  mi 1 1 i second :*  to  set  nr  d  release  a  leek.  The 
LIORATE  was  zero,  simulator*"  a  system  where  all  are 

kept  ir.  main  memory. 

Note  that  NOR  Vi,  LCPM-A7E.  LICE  ATE  ar  :  L-'.V  (from 

the  previous  sectior)  are  Icckirr  ;  .nr  n~v'  ner  s  used  hv  -11 
of  the  corcu rrercv  cortr~l  al  *?  :  r  i  ♦  L~  s  .  Asd:ti:rnl  oarr''  v- 
ters  relevant  to  the  individual  ccr currervv  ccrtrcl  air,  o- 
rithms  are  introduced  ir  the  sectior  doscrihirr  th:s-* 
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al  gor  i  t  hm  s  . 


2.3.3.  Network  Parameters 


The  network  parameters  determine  the  throughput  and 
bandwidth  of  the  network  as  well  as  the  CPU  resources 
required  at  each  site  to  send  and  receive  a  message.  The 
network  parameters  are  summarized  in  Table  3-3. 


The  number  of  nodes  in  the  network,  set  by  the  NNODES 
parameter  was  varied  from  two  to  eight. 


The  message  rate  parameter,  MESRATE,  is  the  length  of 
time  it  takes  to  send  a  simple  message  (i.e.  a  non-data 
transfer  message)  from  one  node  to  another.  Typical 
values  for  this  parameter  ranged  from  1  through  10.  A 
value  of  3,  Cor  example,  would  represent  a  high  speed  net¬ 
work,  where,  under  the  interpretation  mentioned  in  the 
previous  section,  it  would  take  about  90  milliseconds  to 
Table  3-3  Network  Parameters 


Parameter 


Description 


NNODES 

MESRATE 

DATARATE 
MES  E  n;vi 

MES IDEATE 

MESCPUE ATE 


The  r umber  of  nodes  or  sites  ir.  the  network 
The  tim°  units  a  message  must  stay  or  the 
network 

The  time  units  to  transfer  an  entity 

The  number  of  simultaneous  messages  cr 

bandwidth  cf  the  Network  Varager 

The  I/O  time  required  by  a  node  to  send  or 

receive  a  message 

The  CPU  time  required  by  a  rode  to  ser  or 
a  message. 


receive 


deliver  a  message.  A  value  of  10  implies  it  would  take 
about  300  milliseconds  to  send  a  message  ,  about  the  time 
required  or  the  ARPANET  [KLEI761. 

The  DATARATE,  together  with  the  MESRATE  parameter, 
determines  how  long  a  data  trap  smissior.  message  will  take. 
If  E  is  the  number  of  entities  to  be  transmitted,  then  the 
data  transmission  message  would  take 

MESRATE  +  E  *  DATARATE 

time  units  to  be  delivered.  If  an  entity  is  a  512  byte 
page,  and  an  ARPANET  like  file  transfer  at  50,000  bits  per 
secord  is  assumed,  it  would  take  about  0,1  secords  to 
transfer  1  entity.  Or:  the  other  har'd,  or  a  three 
megahertz  speed  network,  it  would  only  take  about  .0015 
seconds.  Many  of  the  simulation  exoerimerts  used  and 
"optimistic”  DATARATE  of  .05  time  units.  Other  simulation 
experiments  used  DATARATES  of  .1,  ..25,  and  .5.  The  MES¬ 
RATE  term  is  included  in  the  above  time  to  represent  the 
initialization  message  which  often  must  precede  a  retwork 
data  transmission . 

The  MESS  DVT  parameter  determines  the  bar.  d  width  .f  the 
retwork  manager.  As  explained  in  sectior  2.2,  at  most 
MESBDVT  messag  es  in  the  network  queue  are  serviced  each 
time  unit.  For  lightly  loaded  retworks,  it  is  reasornble 
to  assume  that  the  bandwidth  is  unbounded  [KLEI76]  and 
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tmt  a  ssumnl  i  or.  is  ir  fa  ct  nado  ir  most  of  the  simulatior 
experiments.  The  results  of  varvir  g  that  parameter  are 
al so  proper  ted  . 

The  MESIORATE  ar  d  XESCPURATE  parameters  represent  the 
resources  required  at  each  rode  to  send  or  receive  a  mes¬ 
sage.  For  these  simulatior  results,  the  MELIORATE  was 
zero,  simulating  that  the  processing  of  all  messages  is 
handled  ir:  the  main.  memory;  and  the  MESCPURATE  has  a  value 
ranging  from  .01  to  .3  time  units;  or  in  the  canonical 
ir;  ter  nr  eta  tior  from  .3  to  9  mil  1  i  secor  d  s  .  For  the  most 
part,  the  lower  bound  or  MESCPURATE  was  used,  simulating  a 
very  low  (and  ontimistic)  overhead  message  processor. 

2 . 3 • ^ •  Output  Par ameter s 

The  quantities  to  be  measured  or.  the  output  parame¬ 
ters  are  summarized  in  Table  3-^.  These  measurements 
include  all  of  the  measurements  included  in  the  central¬ 
ized  database  simulatior  and  some  other  parameters  unique 
to  tv,?  distributed  model. 

The  first  eight  output  parameters  are  identical  to 
the  cutout  parameters  discussed  ir  Charter  2.  The  TCFU 
ar.d  TIC  parameters  refer'  t c  the  r umber  of  simulatior  time 
units  duri:~  which  the  CC  :  ar.d  I  /?  servers  for  all  of  the 
network  nodes  wore  went  busv.  The  LQCKCPM  ar.  d  LOCK  ID 


T  a  b  1  o  ^ 


:♦  : -'it 


1  1 


Parameter  Des<.r  int,  : 

Loo  al 

TCPU 
TIO 

LOCK CPU 
LOCKIO 
TRANCOM 
AVER  RES 
USE^ULCPU 
USEFUL 10 

Distributed 

MFSCPU  CPU  overhead  for'  retwrrk  messages 

MRS  10  I/O  overhead  for  re  tweak  m°s sales 

TMF.SS  The  total  r. umber  of  messaq^s  ?<sr  t 

LMFSS  The  r. umber  of  Lock  related  s^rt 

parameters  refer  to  the  number  of  time  ur its  th^  respev 

tive  servers  were  busy  maratirt  looks.  The  TRANCO1-*  nsram 
eter  is  the  total  number  of  transactions  complete i  u  th 
end  of  a  simulation  run.  Note  that  a  distributed  *  r--:  /a*. 

tier1  ,  regardless  of  the  number  of  ccrresror  i  i  *  ■;  ’LAV 

transactions,  is  counted  as  ot  e  trar  s;Hd  i:  r  .  The  AVER  PE 
parameter  measures  the  average  number  of  time  i::  it?  i 

lakes  for  a  trar  sat  tier  to  :\mr  1  r*t  •• .  For  d;  .  ;tr 

tr  ar  sac  t  i  or  s  ,  th.  e  re  secret  ti,,o  r  fc  *  t  •  »  v  :‘f--r 

erce  betweer  wher.  a  'o’ ta*  v  one  *  :  - r  Lr,r'  •  •••*  to¬ 
per  dirt  queue  ar  d  whe*  that  tr  a  ra;t;*r  1  .  .  ♦<  r  t  ■  •  •  \  wt  r 

dor  e  queue  . 

The  useful  c  c  m  :•  s  t  e  r  ■ ;  t  i  1  :  .*  a  t  :  -  r  ~  .  p:f"!  a  r 


Total  time  the  fh"  ^rv-r  was  a< 
Total  time  tin*  I  /  d  :>  e  r  v  *'•  i  *  w  a  s  a  ^  t :  v  •  * 
CPU  o v  e r  h o  a d  ft*  1  ■  v  k  i  r  . 

I/O  overhead  for  U^r  ir  ^ 

N u m b e r  o  f  t r  a n  jetiv:  s  e  ■:  -m  ?h  1  o  t e d 
Aver  a  < t  e  r  e  s n o  r  s e  t 1 m e 
CPU  time  for  pre^-essi  r  trar  sect:  *s 
1/0  time  for  processir  -T  trar  v  i  r  s 


USEFUL 10  , 


refer' 


to  the 


resour^ rt 


;  r  r>  " 


processing.  These  measuremer: ts  were  not  used  for  con¬ 
currency  control  or  for  message  processing.  Note  that 

TC  PU  =  USEFULC  PU  +  LOCKC  PU  +MESC  PU 

TIO=USEFULIO+LOCKIO+M£SIO . 

The  ME5I0  and  MESCPU  parameters  refer  to  the  time 
required  by  the  I/O  servers  and  CPU  servers  at  the  various 
nodes  to  process  messages.  Note  that  a  message  must  both 
be  sent  and  received,  so  that  the  I/O  and  CPU  costs  to 
send  n  messages  are  r*2*MESI0RATE  and  r*2*MESC  PU  R  ATE 
r  espec  t  i  vel  y .  This  cost  is  also  independent  of  the  mes¬ 
sage  length.  Thus,  for  a  data  transfer  message,  this  cost 
represents  initial  set  up  costs  to  actually  transfer  data 
to  the  network.  No  additional  local  costs  for  the  data 
transfer  are  incurred.  In  some  systems  considerably  more 
overhead  would  be  incurred  for  data  transfer. 

The  TMESS  oarameter  represents  the  total  number  of 
messages  sent  over  the  network.  The  LMESS  Darsmeter  is 
the  number  of  those  messages  which  were  sent  only  for  con¬ 
currency  control  reasors.  The  messages,  called  ’Lock’ 
messages,  are  discussed  when  the  cor. currency  control  algo¬ 
rithms  are  irtroduced. 
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2.4.  Tyj2l£:aI  Sc-erar ios 

The  simulations  were  run  with  the  parameter  settings 
shown  in  Table  3-5.  The  local  parameters  are  identical  to 
the  parameters  in  the  centralized  database  simulatiors  and 
for  the  most  part  were  r.ot  varied.  The  initial  settings 
of  the  distributed  parameters  are  designed  to  study  the 
concurrency  cortrol  algorithms  under  a  basically  free  and 
unlimited  network.  Later  alternate  parameter  settings  are 
used  to  study  the  effects  of  network  limitations  or  the 
different  concurrency  cortrol  algorithms.  The  results  of 
those  experiments  are  reported  in  section  4. 

In  the  next  section,  the  four  concurrency  control 
algorithms  simulated  are  described  and  additional  parame¬ 
ters  required  for  those  algorithms  are  introduced. 

3.  DISTRIBUTED  CONCURRENCY  CONTROL 

The  distributed  database  cor  currer  cy  cortrol  algo¬ 
rithms  car  be  divided  ir. to  two  general  clashes:  primary 
site  concurrency  cortrol  [AL5B76,  MENA7R]  ar  d  do*  'v  t  real¬ 
ized  cor  currer  cy  ccrtrcl  [  S  TOUT?  ,  ELLI7?  ,  ORA  =  ‘  . 

In  the  p  r  i  m  a  r  y  site  c  o  r  currer  c  v  c  c  r  t  r  o  1  s  c  h  °  m  o  r  f :  r  - 
distributed  database,  ore  site  is  chosen  to  er  force  a  pro¬ 
cessing  schedule  equivalent  to  a  global  s**r  in  1 1  z  a  *  i  :  r  :r 


Table  3-B  Typical  Parameter  Settings 


P  ar  nmr' r 

S  e  1 1  i  r  f* 

Loc  a  I 

I  r  term  "tat  i  or 

NT  RAN 

10 

10  trar.s  at  each  rode 

DBS  I  7  e 

1 0 , 000 

10,000  database  entities 
at  eai.h  rode 

A  ME  AN 

5 

0.05%  of  DBSIZF. 

BMEAN 

250 

2.5%  of  DBSIZF. 

ALPH 

.  1 

10%  of  trar.s  are  lar^e 

0 

All  trar.s  are  small 

LKPLMT 

1 

Well-olaced  locks 
(used  with  ALPH  =  .1) 

2 

Randomly  placed  locks 
(used  with  ALPH  =  0) 

C PUR ATT 

1 

30  msecs 

IORATE 

1 

30  msecs 

LC PUR  ATT 

.  1 

3  msecs 

LI OR ATE 

0 

Locks  ir:  main  memory 

Distributed 

PREPIST 

.  1 

10%  of  the  transactions 
are  distributed 

PRETRAM 

.  40 

40%  of  those  require  data 
tr an  sf  er 

PREwATT 

.  25 

25%  of  entities  touched 
by  the  trarsactiors  are 
in  fact  transferred 

NSLAVEP 

5 

A  distributed  trarsactior 
runs  at  all  nodes 

NMOLES 

6 

Six  i odes  in  the  network 

MFSR ATr 

3 

Hi^h  speed  network 

DAT  A  PATE 

.  05 

fast  data  transfer  Network 

mes-:'  -:t 

oo 

Lightly  loaded  r etwork 

MRS  I OR  ATE 

0 

Messages  handle*  1 r  c  0  r  r 

MESS  P'J  RATE. 

.01 

.3  msecs  (very  optimistic.) 

al  1 

of  the 

t  r  a  r  s  a  c  t  i  0 

r  s  r u r  r i r  s  at 

all  sites. 

Two 

st  r  a 

i rht f  orwar 

d  imrleme 

r  t a t i 0 r  s  of  a 

orimary  s 

i  te 

model 

are 

cr  0  so  r ted 

ir  sectior 

s  3.1  and  3.2. 

Basic  a 11 

y  » 

if  a 

prim 

ary  site 

handles 

all  c  cr  ourrc-r  c  \ 

;  cor  trol , 

the 

same 

algorithm  used  for  a  centralized  database 


car  be  used  for 


the  distributed  data  h  n  s  e  . 


In  the  deeer  trali'/ed  ccr  v  wrrer  cv  c  .  t  I  o;  rf*  . 
each  site  maintains  its  owr  leeks  for  that  :utpf  ■  ncc 
of  the  database.  However,  a  deadlock  :  d  1  t  i 
can  exist  ir:  the  network  ever,  though  r.o  don'iVck  i  y> 
exists  at  any  given  node.  For  example  Trnr  sa*.  tier  1 

be  blocked  at  node  i  by  Trar.savtior  2.  At  r.od'*  ,  h- 

ever,  Transaction  2  can  be  blcvked  by  Trarsnchio: 
Although  no  deadlock  exists  at  either  rode  i  or  i,  reitf 
Transaction  1  r.cr  Trarsaotior  ?  can  be  completed, 
mechanises  and  their  simulatior  impleme: .tntio?  r  for  ;o: 
irg  with  this  deadlock  problem  are  presetted  ir  secti: 
3.3  and  3.4. 


3.1.  Primary  Site  Model  1 


The  concurrency  cor trol  mechanisms  ir.  both*  t v: o  pr 
mary  site  models  require  the  following  charges  to  the  r.c 


model  shown  ir:  figure  3-2: 


When  ary  trnr. s' 


Der.dirg  queun  ,  a  rlobO 


rode  selected  as  th 


ther  waits  r 


-  -  -  u  ^  1  ~  r.  1 


u  r  t  i  1  all  of  its  1  c  k  s  a r<  *  r  t 


2)  When  a  global  lock  grant  is  received,  the  transaction 
can  proceed  to  the  I/O,  CPU  and  data  transmission 
queues  as  before.  At  this  time,  a  MASTER  transaction 
starts  its  corresponding  SLAVE  transactions . 

3)  Upon  receipt  of  a  "SLAVE  create"  message,  a  new  tran¬ 
saction  identical  to  the  MASTER  transaction  is  placed 
directly  on  the  I/O  queue. 

*0  As  in  section.  2.2,  a  MASTER  transaction  waits  or.  the 
Network  done  queue  until  it  has  received  "SLAVE  com¬ 
plete"  messages  from  each  of  its  SLAVES.  At  this 
point,  a  MASTER  transaction  sends  a  "global  lock 
release"  message  to  the  PRIMARY  site  and  is  recycled 
back  to  the  pending  queue. 

5)  In  the  PRIMARY  site  model,  a  SLAVE  transaction  need 
not  wait  on  the  Network  done  queue;  it  car.  simply 
send  its  "SLAVE  complete"  message  and  leave  the  sys¬ 
tem  . 

Note  that  the  "global  lock  request",  "global  lock 
grant",  and  "global  lock  release"  messages  are  all 
included  in  the  lock  message  court.  Also  rote  that  the 
"global  lock  request"  includes  th?  lock  requests  fcr  all 
of  the  SLAVES. 


In  the  primary  site  model,  the  nodes  are  considered 
to  be  numbered  zero  through  NNOPFS  -  1.  For  each  node, 
there  is  a  "blocked”  queue  and  a  "locks  held”  queue  as 
shown  in  figure  3-3. 

When  a  "global  lock  request"  is  received,  the  PRIMARY 
site  lock  controller  goes  through  the  following  steps: 

1)  Determine  which  nodes  will  be  used  by  the  requesting 
transaction . 

2)  For  each  node,  i  =  0,...,NN0DES  -  1,  see  if  this 

transaction  requires  locks;  if  not,  proceed  to  the 
next  node.  If  so,  request  the  locks  (identical  to  a 
lock  request  in  Chapter  2)  required  at  this  node. 

3)  If  the  locks  are  granted,  record  this  fact  or  the 

"locks  held"  list  for  rode  i  and  repeat  step  2  for 

nodei+1 . 

4)  If  the  locks  are  defied,  dace  the  trar  sac  tier  or  the 

blocked  queue  for  r  ode  i,  recording  the  b  1  '  k i r  o 
trar.sactior  which  is  or  the  "locks  held"  rjueue  for 

this  node. 

5)  When  the  locks  at  all  of  the  required  redes  are 

granted,  a  "global  locks  graded"  message  is  sort  t: 

the  originating  site. 


Figure  3~ 3: 


When  a  ,f global  lock  release1'  is  receive  1,  the  PRTMARY 
site  lock  controller  removes  the  correspor  d  in  g  tr  ar.  sac t  i  or 
from  each  of  the  "lock  held”  queues.  Ary  trar  sac  tier 
which  was  blocked  at  rode  i  by  this  trar sootier  is  res¬ 
tarted  at  step  2  for  rode  i,  in  the  above  algorithm. 

The  following  observations  should  be  noted.  First, 
deadlock  is  impossible,  since  the  locks  at  the  differer.  t 
sites  are  always  acquired  in  a  fixed  order.  Sec:  or  d,  LOCAL 
transactions  will  only  be  involved  with  locks  at  their 
originating  sites.  Third,  note  that  a  nor: -local  transac¬ 
tion  can  wait  for  locks  at  ore  node  while  holding  looks  at 
a  lower  numbered  node. 

All  of  the  locking  costs  are  absorbed  by  the  primary 
site  which  also  has  a  normal  load  of  transaction  process¬ 
ing.  The  use  of  the  CPU  and  I/O  servers  by  the  primary 
site  control  mechanism  has  a  preemptive  priority  over 
transaction  processing  requests.  In  other  words,  if  there 
are  global  lock  releases  or  requests,  the  PRIMARY  site 
first  has  to  serve  those  requests  before  it  car  process 
any  t  r  a  r.  s  a  c  t  i  o  r  s  .  If  serving  those  requests  t  a  k r-  s  m ;  r  e 
than  ore  simulation  time  ur.it,  r.o  transactor  rr.\es sire 
takes  place  during  that  time  unit. 
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3.2.  Primary  Site  Model  2 

The  activities  at  each  site  of  the  distributed  data¬ 
base  are  identical  ur der  this  model  and  the  previous  pri¬ 
mary  site  model  described  above.  The  only  difference  in 
the  two  models  occurs  in  the  Primary  site  lock  control. 
In  this  model,  there  is  only  ore  blocked  queue,  although 
there  is  a  'locks  held'  queue  for  each  node. 

When  a  "global  lock  request"  is  received,  the  PRIMARY 
site  lock  controller  goes  through  the  following  steps: 

1) -3) Same  as  in  previous  primary  site  model. 

*0  If  the  locks  are  denied,  release  all  of  the  locks 
held  for  lower  number  nodes,  record  the  blocking 
transaction  and  place  this  transaction  or.  the  single 
blocked  queue. 

5)  Same  as  ir  the  previous  primary  site  model. 

When  a  "global  lock  release"  is  received,  the  PRIMARY 
site  ccrtrcllor  again  releases  the  locks  held  at  each 
rode.  Ary  trsrsBvtior  which  was  blocked,  is  restarted  at 


step  1  cf  the  ah 

n  v  •?  a  1  g  oi*  i  t  hm  . 

This  mode] 

differs  f  r  c  m  the 

crevicus  ted  el 

ir 

two 

ways.  The  ma  ir 

difference  is  th 

at  r .  o  tr  ar  sac  t  i  or 

c  ar 

hold 

1 ' '  • 


locks  at  one  node  while  wnitir  (»  for'  locks  from  ar  other 
rode.  This  difference  "rears  that  trar  nactior  s  roquirir,;  a 
fewer  number  of  nodes,  (i.e.,  local  trar.  sac  tior  r.)  have  ar' 
implicit  priority  over  transactions  requiring  lock'-  at 

more  nodes. 

3*3.  Wound- Wait  Model 

As  previously  mentioned,  decer:  tral  i  zed  concurrency 
control  requires  a  mechanism  for  resolving  deadlock.  Ir: 
this  section  an  extension  of  a  "wound-wa i t "  scheme 
[ROSE77]  for  resolving  deadlock  is  discussed.  First  the 
original  algorithm  in  [ROSE??]  is  presented,  followed  by 
two  extensions.  Finally,  additional  changes  ir:  parame¬ 
ters,  relevant  to  the  "wourd-wai  ttf  algorithm  are  reviewed. 

1*1*1*  Original  Wourd-Wai t  Algorithm 

In  [ROSF77],  the  transactior  me  iel  is  slirhtly  dif¬ 
ferent  than  the  ore  presented  ir:  this  chanter.  A  tr  arson- 
tior  is  viewed  as  a  process  which  is  iri  tinted  at  -re  r  :  ie 
and  moves  from  node  to  rode  ir  the  course  of  its  r^:c cas¬ 
ing.  At  any  irstaree  the  process  is  cor  si  derod  at 

or.e  node  ar.d  ir  act i ve  at  all  other  r  odes  that  :t  has 


visited. 
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Ur. dor  the  wotir  d-wa  i  t  algcrithm,  a  unique  number, 
ass  igred  to  each  process  or  In  ar  sactior.  ,  is  obtained  by 
core  a  ter  at  i  r.  g  a  starting  tine  with  the  node  number  at 
which  the  process  is  initiated.  (The  algorithm  does  not 
require  that  the  clocks  which  generate  the  time  stamps  be 
perfectly  synchronized.  However,  some  close  correspon¬ 
dence  with  the  ’’real”  time  would  be  desirable.  In 
[LAMP??],  a  sufficient  algorithm  for  keeping  clocks  at 
nodes  in  a  network  reasonable  synchronized  is  presented.) 

Suppose  Tran  sac  tior.  1  requests  locks  held  by  Trar.sac- 
tior  2  ar.d  that  timestamp  1  and  timestamp  2  are  the  unique 
numbers  associated  with  the  two  transactions.  Then  the 
following  steps  are  taker;: 

1)  If  timestamp  1  <  timestamp  2,  then  Transaction  1  is 
"older11  than  Transaction  2.  In  this  case,  Transaction 
2  is  wounded  and  Transaction  1  waits. 

2)  If  timestamp  2  <  timestamp  1,  then  Transaction  2  is 
"older”  than  Trar  sacticr  1.  Ir.  this  case,  Transac¬ 
tion  1  simply  malts. 


If  Trar.sac-tirr  2  is  weirded, 
site"  visited  by  Trar  30, tier  2. 
s  a  c  t i : r  2  has  a 1 r  e  a d y  h -  *  ir  ,  t n e 


a  messare  is  sort  to  all 
If  t  e  r  m ; r  a  t  i  c  r  of  Trar- 
w  0  u  r  1  is  i  *7  r  o  r  e  d  ,  sir.ee 

its  leeks  a  r  d  T  r a  r  s  a  c  t i c  r 


c  o 


1  can  proceed.  -If  Transaction  2  has  riot  begin  trie  termi- 
natior  process,  it  is  aborted  (or  killed)  ar.d  rest  ar  ted  . 
A^air:,  the  locks  held  by  Transactior  ?  are  released  ard 
Transaction  1  can  proceed.  Note  that  in  order  to  prevert 
cascading  abortions  of  tr  an  sac  t  i  or  s ,  all  locks  for  a  giver: 
transaction  are  held  until  that  transaction  terminates. 

A  natural  modification  to  this  algorithm  is  suggested 
in  [RQSE771,  where  Transactior  2  is  rot  aborted  ar 1  res¬ 
tarted  unless  it  is  actually  in  or  enters  a  waiting  state. 

This  algorithm  provides  a  consistent  concurrency  cor- 
trol  for  which  every  transactior  terminates.  Cor.si_terey 
is  maintained  because  a  transaction  holds  all  leeks  until 
it  has  completed.  Thus,  two-phased  locking  :s  insured. 
To  see  that  every  transactior  terminates,  note  that  at  arv 
giver  time,  due  to  the  uniqueness  of  the  timestamp,  there 
is  exactly  ore  "oldest"  transactior..  That  tr  ar  sac  1 1  c  r  oar 
never  be  wounded  ar.d  thus  must  terminate.  At  that  point, 
there  is  a  new  "oldest"  transactior  which  also  must  ter¬ 
minate.  A  transactior  retains  its  crigiral  t.  on  tv::.  eve: 
if  it  is  restarted. 

3-3.2-  Simula  tic :  I m  o 1 o  m  e  r t  a  t  i  c  r 

To  apply  the  above  algorithm  tc  the  distr i :  jte  1  tr  m- 
sacticr  processir  g  discussed  in  this  c  harder,  it  -  jst 
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first  be  noted  that  a  wounded  trarsactior  can  be  active  at 
more  than  ore  site.  Thus,  the  decisior  to  abort  and  res¬ 
tart  a  trar:  sac  tier,  might  be  initiated  at  several  sites.  A 
wound  or  kill  message  for  an  already  killed  transaotior  is 
simply  ignored.  When  a  trarsactior  is  restarted  a  ’cycle 
number'  is  incremented.  The  cycle  number,  initially  zero, 
is  included  ir.  the  message  addresses  so  that  the  restarted 
transaction  does  not  erroneously  receive  an  old  wound  or 
kill  message. 

A  second  simple  modification  to  the  [ROSE77]  algo¬ 
rithm  was  also  made.  A  trarsactior  receiving  a  wound  mes¬ 
sage  is  not  restarted  unless  that  transaction  is  blocked 
by  or  becomes  blocked  by  a  transaction  that  the  original 
trarsactior:  cannot  wound.  In  other  words,  a  wounded  tran¬ 
saction  must  be  restarted  if  and  only  if  it  is  blocked  by 
an  older  tr ar:  sac t ior: .  Note  that  this  algorithm  still 
resolves  any  potential  deadlock  and  all  transactions  must 
ever. tu ally  terminate. 

Theorem;  This  modified  wound-wait  system  still  preserves 
ecrsister.cy  and  every  process  terminates. 

Proof:  The  database  c:r  sister  cy  is  preserved  since  the 

lcckiro  is  still  two -chased. 

Every  process  will  term  irate,  since  a  deadlock  cycle 
carr.ct  exist  ir  the  wait.-for  graph.  The  wait-for  craph  is 
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a  directed  granh  where  the  rrdos  rer^so r  t  tra:  ro;  4  :  r  s  lr 
the  system.  An  arc  from  ere  node  to  another  imolier  that 
the  fsrst  rode  represents  a  transact  j  or  that  is  blc.k^j  ty 
the  trarsactior  represer:  ted  by  the  sec  or  d  rode. 

Suppose  a  deadlock  cycle  existed  in  the  graph  botweer 
nodes  T^f...,Tr  (i.e.,  is  blocked  by  T^  ,  T^  is  blocked 
by  ^n-1  *s  blocked  by  *  and  is  blocked  by 

).  Without  loss  of  generality,  assume  is  the  oldest 
transaction.  Then  must  wound  . 

If  can  wound  T^,  it  does.  If  not,  is  aborted  ar:d 

the  deadlock  no  longer  exists. 

Similarly,  if  any  cannot  wound  Ti+1»  it  must  be 

aborted  . 

If  all  of  the  (i  =  2  ,  .  .  .  ,  r  )  are  wourded,  so  is  T  . 

But  is  blocked  by  and  cannot  wound  T ^  because  of  our 
assumption  s . 

Thus,  must  be  aborted  ar  1  restarted  a:  d  the  j e a  :  1  oc  *■; 
cycle  is  broker  . 

r  t  4 

To  implemert  the  a  b  ;  :  e  al  ^cr  i  *.  ,  50  v  ~ :  : :  f ;  v  -  - 

tiors  to  the  Simula t:-r  were  y  ;  r  s  t  ,  t  :,v-  i  7  - ; 

time  of  each  trar sac  tier  w  ^  s  n-r  v  :r  ;  7  ov 

i  r  s  u  r  i  r  g  that  all  t  r  a  r  s  a  c  1 1  c f  s  arrived  ' 4  1  0  a  r.  t  0  re  *  n  o 
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unit  apart.  Thfe  arrival  time,  core aten ated  with  a  rode 
number,  in  the  least  significant  bits,  is  the  unique 
timestamp  associated  with  the  transaction.  In  addition,  a 
cycle  number  is  added  to  each  transaction  in  order  to 
insure  that  a  restarted  transaction  is  not  wounded  or 
killed  by  a  message  intended  for  an  earlier  incarnation. 
When  a  transaction  (SLAVES  excepted)  is  first  placed  or. 
the  pending  queue,  the  cycle  number  is  initialized  to 
zero.  Messages  are  only  delivered  to  transactions  with 
the  correct  cycle  numbers.  Messages  destined  for  earlier 
cycles  are  simply  discarded.  A  SLAVE  transaction  takes  on 
the  timestamp  and  cycle  number  of  its  corresponding  MAS¬ 
TER.  The  following  steps  are  now  followed  by  a  transac¬ 
tion. 

1)  A  transaction  leaves  the  pending  queue.  If  the  tran¬ 

saction  is  a  MASTER  and  this  is  the  first  time  this 
incarnation  has  left  the  pending  queue,  "SLAVE 

create"  messages  are  sent  to  the  appropriate  nodes. 

2)  After  leavirg  the  pending  queue,  a  transaction 
requests  the  locks  reeded  at  that  site.  If  the  locks 
are  granted  the  transactiot  proceeds  to  the  I/O,  CPU 
and  data  trarsmissicr  queues.  If  the  leeks  are 
denied,  the  trarsacticr  is  nlac-ed  on  the  blocked 
queue  for  this  node.  Let  T1  be  the  requestirg  trar- 
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sactior:  and  12  be  the  blocking  transnctior  res  posi¬ 
tively.  If  both  T1  and  T?  are  distributed  transac¬ 
tions  (SLAVES  or  MASTERS)  and  T1  is  older  than  12, 
transaction  12  is  "wounded".  If  T1  is  younger  than. 
12  and  has  been  previously  wounded,  T1  is  killed. 

3)  Once  the  locks  are  granted,  the  trar.sactior  s  proceed 
on  the  I/O,  CPU  and  data  tr an smi ssior  queues  as 

before . 

4)  A  SLAVE  transaction  sends  a  "SLAVE  complete"  message 
to  its  MASTER  and  waits  or  the  Network  dor e  queue  for 
a  release  locks  message.  A  MASTER  trar.sactior  waits 
on  the  Network  done  queue  until  all  of  its  SLAVES 
have  compl eted . 

5)  When  all  of  the  SLAVES  have  completed,  the  MASTER 
sends  a  "release  locks"  message  to  all  of  its  SLAVES, 
releases  its  locks,  and  becomes  a  rew  transact! or  or 
the  pending  queue.  At  this  point  the  trar  ?  .an  tier  is 
considered  dore.  When  a  SLAVE  receives  t  h*->  "release 
locks"  message,  it  releases  i‘s  locks  ar  i  l^av-'s  the 
system , 

6)  When  ary  trar  sactior  releases  its  1'cks,  the 
corresponding  blocked  trar  sactior  s  (if  ary)  rare 
placed  at  the  fror t  of  the  per  ding  queue. 
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When  a  transaction  is  wounded,  "wound"  messages  are 
sent  to  the  MASTER  and  all  SLAVES.  When  a  transaction 
receives  a  wound,  it  is  flagged  as  wounded.  If  the  tran¬ 
saction  is  already  blocked  by  a  distributed  transaction 
with  an  older  timestamp,  the  wounded  transaction  is 
immediately  "killed". 

When  a  transaction  is  killed,  "kill"  messages  are 
sent  to  the  MASTER  and  all  SLAVES.  Both  types  of  transac¬ 
tions  release  their  locks  and  blocked  transactions  are 
placed  on  the  front  of  the  pending  queue  as  in  step  6 
above.  Any  time  spent  or:  the  I/O  or  CPU  queues  is  counted 
in  a  "lost  time"  total.  At  this  point  SLAVE  transactions 
leave  the  system.  A  MASTER  transaction  increments  its 
cycle  number  and  is  placed  on  the  back  of  the  pending 
queue  for  a  reincarnation. 

A  few  observ  ation  s  should  be  made.  First,  in.  step  2, 
only  if  both  transactions  are  non-local,  does  a  potential 
wound  have  to  take  place.  If  the  blocking  transaction  is 
local,  it  is  guaranteed  to  finish  since  it  has  preclaimed 
all  of  its  locks.  If  the  blocked  trarsacticr  is  local,  it 
car:  hold  no  locks  at  ether  sites  and  thus  re  deadlock  can. 
occur. 

Second,  -when  a  trarsacticr  is  restarted,  it  is  placed 
on  the  pending  queue  behird  any  trarsacticr s  that  it 


blocked . 


In  particular, 


it 


is  placed  behind  the 
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transaction  that  caused  the  original  wound.  Thus,  the 
same  wound  will  not  occur  again  . 

Note  that  the  extra  "release  lock”  messages  to  the 
SLAVES  are  riot  present  in  the  primary  cor. currency  control 
models.  They  are  not  needed  in  those  models  because  all 
locks  are  held  (and  thus  released)  at  the  primary  site. 

3.3.3.  Additional  Parameters 

Four  additional  output  parameters  were  recorded  in 
the  simulation  model  for  the  " wour.d-wai t"  corcurrer  cy  con¬ 
trol.  In  addition,  new  tynes  of  messages  are  classified 

as  lock  messages. 

The  four  output  parameters  are  for  the  number  of 
transactions  wounded  ( NT R WOUND) f  the  number  of  transac¬ 
tions  killed  (NTRKILL),  and  the  lost  time  attributed  to 
killed  transactions  (DLOSTIO  and  DLOSTCPU).  The  court  of 
the  number  of  transactions  wounded,  NTRV0UND,  is  made  only 
when  a  cycle  of  a  given  MASTER  receives  its  first  wound. 
Thus,  even  though  the  SLAVES  all  receive  wound  messages, 
the  wounding  of  a  distributed  trarsactic-r  ir  or  1  v  ^  ■  ,jr  tei 
once . 

Similarly,  the  ccur.t  of  the  r  umber  of  trar.  so-  t::r  s 
killed  ,  NTRKILL,  is  "iaie  orly  wrer  a  MAf:TE!?  r«v  <?  1  its 

first  ki 11 . 


The  DLOSTIO  and  DLOSTCPU  parameters  record  the  number 
of  time  units  of  I/O  and  CPU  service  respectively  that. a 
killed  transaction  has  received.  How  much  time  is  actu¬ 
ally  lost  depends  on  both  the  queue  the  transaction  is  or. 
and  the  processing  completed  at  that  queue.  Note  that  the 
definition  of  the  total  I/O  utilization,  TIO  and  the  total 
CPU  utilization,  TCPU  also  changes: 

TIO  =  USEFULIO  +  MES10  +  LQCKIO  +  DLOSTIO 

TCPU  =  USEFULC  PU  +  MESCPU  +  LOCKCPU  +  DLOSTCPU. 

In  the  " wound-wa i t"  concurrency  control  algorithm  for 
a  decentralized  database,  "WOUND",  "KILL",  and  "lock 
release"  messages  are  all  counted  as  lock  related  mes¬ 
sages.  The  lock  related  messages  used  in  the  primary  site 
models  are  no  longer  relevant. 

3.^.  SNOOP  Model 

A  second  decentralized  concurrency  control  algorithm 
uses  a  ’SNOOP’  [STON793  or  a  global  deadlock  detector 
[GRAY73]  was  also  simulated.  One  problem  with  the 
" wour d - w a i t "  algorithm  is  that  transactions  may  be  killed 
and  restarted  needlessly.  While  the  algorithm  is  suffi¬ 
cient  to  prevent  deadlock,  it  may  be  too  cor servati ve . 
Transactior.  1  could  be  blocked  by  the  younger  Transactior 


2.  Transaction-  2  could  be  blocked  by  the  older  Transac¬ 
tion  3,  which  can  in  fact  complete.  Even  though  no 
deadlock  is  present,  Transaction  2  would  still  be  res¬ 
tarted  . 

In  this  section,  an  algorithm  is  described  which  res¬ 
tarts  transactions  only  when  an.  actual  deadlock  occurs. 
In  section  3-^.2,  the  implementation  of  that  algorithm  in 
the  simulation  model  is  presented.  In  section  3.^.3 
changes  in  the  simulation,  parameters  are  discussed. 

SNOOP  Algorithm 

In  [STON78]  a  decentralized  algorithm  for  concurrency 
control  is  presented.  Each  node  or  site  in  the  distri¬ 
buted  database  is  responsible  for  local  concurrency  cor  - 
trol  for  the  portion  of  the  database  at  that  site.  If  two 
transactions  conflict,  the  local  concurrency  cor trol  sends 
a  message  about  this  conflict  to  a  designated  site  called 
’The  SNOOP’. 

—  4*9 

The  SNOOP  then  detects  deadlock  by  aralvs: s  : f  the 
"wait^for"  ^raoh  ^er.erated  by  ail  su^h  w,osc.v .  If  a 
deadlock  cor.ditior  is  detected,  a  victim  is  ricKed  to  be 
killed  ar.d  restarted  (a  reir c arr at i  :r  '  ,  Note  that  wher  a 
trarsactior  has  completed,  the  S*.'b~P  T.ust  also  be  r.otified 
so  that  the  appropriate  er  tries  lr  the  "wait-for1’  r.raph 


can  be  cleared .  * 


The  same  basic  idea  was  also  suggested  in  [GR AY78 ] 
with  several  modifications .  One  modification  is  that  a 
conflict  message  is  only  sent  to  the  SNOOP  if  the  blocking 
transaction  is  directly  waiting  on  a  response  from  another 
node  or  is  blocked  (directly  or  indirectly)  by  some  other 
transaction  that  is  waiting  on  a  response  from  another 
node . 

Another  suggested  modification  is  to  only  send  such 
conflict  messages  and  check  for  deadlock  periodically.  In 
this  manner  the  system  overhead  for  both  handling  lock 
messages  and  checking  for  deadlock  can  be  reduced  at  the 
cost  of  delaying  the  detection  of  an  existing  deadlock. 

3.^.2.  Simulation  Implementation 

The  ’SNOOP*  simulation  model  is  very  similar  to  the 
wound-wait  model.  The  following  steps  are  taken  in  the 
1  SNOOP  1  model. 

1)  Same  as  "wound-wait”  model 

2)  Same  as  "wound-wait"  if  the  locks  are  granted.  Sup¬ 
pose  the  locks  are  denied  and  T1  is  the  requesting 
transaction  and  T2  is  the  blocking  transaction.  If 
both  T1  and  T 2  are  distributed  transactions  (SLAVES 


or  MASTERS),  a  cor  flic  t  message  is  ser.  t  to  or  e  of  the 
sites  designated  as  the  SNOOP. 

3,*0  Same  as  "wound- wa i t"  model. 

5)  Same  as  "wound-wai t"  except  that  when  a  MASTER  tran¬ 
saction  is  done*  a  "clear  snoop"  message  is  sent  to 

the  SNOOP. 

6)  Same  as  "wound-wait"  model. 

The  SNOOP  maintains  a  global  "wait-for"  directed 
graph.  Each  node  represents  a  blocked  or  blocking  tran¬ 
saction.  An  arc  from  node  1  to  node  2  implies  that  the 
transaction  represented  by  node  1  is  blocked  by  the  tran¬ 
saction  represented  by  node  2.  When  a  conflict  message  is 
received,  a  node  for  each  transaction  (if  ore  doesn't 
already  exist)  is  added  to  the  graph  along  with  the 
appropriate  arc.  At  that  point,  the  graph  is  searched  for 
a  cycle  beginning  at  the  node  for  the  blocked  transaction. 
If  deadlock  is  detected,  the  youngest  (determined  by  the 
unique  timestamp)  of  the  two  transactions  involved  with 
this  conflict  is  declared  a  victim  ar.d  killed.  The  fact 
that  a  giver,  cycle  of  the  victim  was  killed  is  remembered 
by  the  SNOOP. 


u 


136 

The  killing  of  a  transition  is  identical  to  the  kil¬ 
ling  of  a  transaction  it',  the  wound-wait  algorithm.  The 
SNOOP  sends  a  message  to  the  MASTER  and  its  SLAVES.  Both 
types  of  trhrsactiors  release  locks  and  record  lost  time. 
A  MASTER  transaction  is  reincarnated  as  in  the  wound-wait 
mod  el  . 

Note  that  it  is  necessary  that  the  SNOOP  remembers 
both  killed  and  completed  transactions  for  a  given  period 
of  time.  It  is  possible  that  the  SNOOP  could  be  notified 
of  a  conflict  involving  a  killed,  or  completed  transac¬ 
tion.  In  these  cases,  the  conflict  occurred  before  a  node 
received  the  ’kill1  or  ’release  locks*  message.  In  the 
case  of  a  killed  transaction,  a  false  deadlock  could  be 
detected.  In  the  case  of  a  completed  transaction,  an 
extra  rode  would  simply  clutter  the  wait-for  graph.  If  a 
killed  or  completed  transaction  is  involved  in  a  conflict 
message,  the  message  is  simply  ignored  at  the  SNOOP  site. 

The  cycle  number  is  needed  by  the  SNOOP  tc  distin¬ 
guish  between  messages  mear  t  for  different  incarr.atiors  of 
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ir.  the  graph.  If  a  ccrflict  message  arrives  with  a  lower 
cycle  r umber  than  the  ccrresrrrlirg  r ode  ir  the  graph,  the 
message  is  simply  iiscaried.  Such  messages  are  cbsrlete. 
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Also  rote  that  in  the  case  of  do H-.llock,  the  victim  is 
chosen  from  amor. ft  the  two  nodes  irvclved  ir:  this  ccrflict. 
This  choice  is  guaranteed  to  break  any  deadlocks  sirce  the 
graph  is  assumed  to  be  deadlock  free  before  the  latest  arc 
was  added.  This  victim  may  not  be  the  optimum  victim  for 
backout.  However,  if  a  different  victim  were  chosen,  the 
other  parts  of  the  graph  would  still  have  to  be  searched 
for  other  deadlock  cycles* 

Finally  note  that  all  conflicts  between  non-local 
transactions  are  sent  immediately  to  the  SNOOP.  As  previ¬ 
ously  mentioned,  it  is  suggested  that  the  corflict  mes¬ 
sages  should  not  be  sent  unless  the  blocking  trar.sacticr 
actually  enters  a  "node  wait”  state.  However,  in  this 
model,  both  MASTER  and  SLAVE  trar.sacticr  s  will  eventually 
wait  for  messages  from  other  nodes  before  they  release 
their  locks.  Since  that  'node-wait*  state  is  inevitable, 
the  corflict  messages  are  sent  immediately. 

3.4.3.  SNOOP  Parameters 

As  with  the  ”  wour.d-wa  i  t  ”  al ~cr  i  t h~  ,  sevr-ai  *  ew 
parameters  are  introduced  ar  d  t  he  defir  i  t :  :r  of  1  ; .  m  o  r  - 

sages  is  char  ged . 

The  cost  to  check  far  deadlock  is  very  e>':er^ivo; 
often  this  cost  is  much  r r  e  -  t  e  r  h.r  t h 0  c  :  t  '  s ^  t  a 
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simple  lock  [GRAY78],  A  new  network  input  parameter, 
SNOOPRATE,  was  added  to  the  simulation  to  model  that  addi¬ 
tional  cost.  Every  time  a  conflict  message  is  received  by 
the  SNOOP,  SNOOPRATE  time  units  are  added  to  the  locking 
costs  at  the  SNOOP  node.  Note  that  conflicts  involving 
killed  or  completed  transactions  are  not  included.  In 
most  of  the  experiments,  a  SNOOPRATE  of  .5  is  used.  In 
the  canonical  interpretation,  this  value  represents  about 
15  milliseconds  or  about  5  times  the  cost  to  set  a  lock. 

The  NTRKILt,  DLOSTIO,  and  DLOSTCPU  parameters  from 
the  wound-wait  model  are  also  included  in  the  SNOOP  simu¬ 
lation.  However,  rather  than  the  NT R WOUND  parameter,  the 
SNOOP  model  records  the  NUMCONFLCT  parameter,  the  number 
of  actual  conflict  messages  received.  Again,  conflict 
messages  for  already  killed  or  completed  transactions  are 
not  included  in  this  count. 

The  lock  messages  in  the  SNOOP  model  are  the  'con¬ 
flict'  messages,  the  'kill'  messages,  the  'release  locks' 
messages  and  the  'clear  SNOOP'  messages. 


4.  RESULTS  AN D  .DISCUSSION 

The  results  for  the  distributed  database  simulatior  s 
are  presented  ir;  this  sectior  .  In  the  first  sectior  we 
present  the  results  for  the  parameter  set tin's  for  the 
canonical  scenarios.  Subsequent  sections  review  the 
effects  of  varying  the  number  of  SLAVES  for  each  distri¬ 
buted  transaction  (NSLAVES),  the  number  of  nodes  in  the 
network  (NNODES),  and  the  percent  of  distributed  transac¬ 
tions  ( PREDIST ) . 

In  section.  4.5,  the  results  of  varying  the  network 
parameters  are  repeated.  These  parameters  are  the  message 
rate  (MESRATE),  the  network  bandwidth  (MESRDWT),  the  CPU 
rate  for  processing  messages  (MESCPURATE)  and  the  percen¬ 
tage  of  data  transferred  (PRETRAM  and  PREDATT).  Finally, 
the  canonical  cases  are  revisited  in  section  4.6  with  a 
different  network  environment. 

The  results  are  reported  for  each  of  the  four  con¬ 
currency  control  algorithms  simulated  and  the  two  dif¬ 
ferent  classes  of  transaction  sizes.  The  first  primary 
site  model,  where  locks  for  one  site  are  held  while  wait¬ 
ing  for  locks  at  another  site,  is  denoted  "PS1".  The 
second  primary  site  model  is  denoted  "PS2".  The  notatior 
"WW"  refers  to  the  wound-w; it  algorithm,  while  "SNOOP" 
refers  to  the  algorithm  with  the  single  global  deadlock 
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detector. 

Transact iors  in  class  1  refer  to  transactions  whose 
sizes  are  generated  by  a  hyperexponential  distribution  and 
well-placed  locks  are  assumed.  Transactions  in  class  2 
refer  to  transactions  whose  sizes  are  mainly  small  (gen¬ 
erated  by  an  exponential  distr ibution )  .  In  this  case, 
random  lock  placement  is  assumed. 

In  the  first  three  sections,  an  unlimited  network  is 
assumed  in  order  to  study  the  effects  of  the  different 
concurrency  control  algorithms  on  the  processing  at  each 
of  the  nodes.  Beginning  in  section  4.4,  network  limita¬ 
tions  are  introduced  to  study  the  effects  of  the  con¬ 
currency  control  algorithm  or.  the  network  resources. 

4  .  K  The  Canonical  Seer' ar  ios 

The  canonical  scenarios  refer  to  the  cases  where  the 
input  parameters  have  the  settings  shown  in  Table  3-5. 
For  these  experiments,  as  in  Chapter  2,  the  number  of 
locks  (NGRAN),  was  varied  from  1  up  to  DBSIZE  and  reflects 
the  number  of  locks  at  each  node.  One  lock  implies  that 
at  each  node,  only  one  transaction  can  be  active  at  ore 
time.  With  10,000  locks,  there  is  one  lock  for  each 
entity  at  each  node  and  transactions  can  proceed  if  the 
entities  they  require  are  not  being  accessed  by  any  other 
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transaction . 

Table  3-6  shows  the  expected  r.umbor  of  each  type  of 
message  under  the  canonical  parameter  settings.  Each 
non-local  transaction  sends  5  (MSLAVE)  slave  create  mes¬ 
sages  and  receives  5  slave  completed  messages.  In  addi¬ 
tion,  U0%  (PRETRAN)  of  the  non-local  transactions  send  6 
(NSLAVES  +1)  data  transfer  messages.  These  riot-local  mes¬ 
sages  are  the  same  for  all  four  concurrency  control  algo¬ 
rithms  . 

However,  the  four  algorithms  send  different  numbers 
of  lock  messages.  In  the  primary  site  models,  transac¬ 
tions  at  5  of  the  6  nodes  (all  nodes  other  than  the  pri¬ 
mary  site)  have  three  lock  messages:  "request  locks", 
"grant  locks",  and  "release  locks".  In  the  decentralized 
models,  only  the  non-local  transactions  send  lock  mes¬ 
sages.  Those  messages  include  the  5  (NSLAVE)  release  lock 
messages  plus  some  messages  for  wounding  transactions, 

Table  3-6 

Expected  Messages  per  Transaction 

PS1-PS2  WoW-SNOOP 


Local 

Non- local 

Loc  al 

Nor- loc  a 1 

Non-lock 

Messages 

0 

10+ (.4)6 

0 

10+( .4)6 

Lock 

Messages 

3(5/6) 

3(5/6) 

0 

5+?  (WW) 
5+  (5/6 )  +  ? 
(SNOOP) 

1  M2 


killin’  transactions  and/or  notifying  the  SNOOP  of  con¬ 
flicts.  In  addition,  in  the  SNOOP  model,  a  nor.-local 
transaction  at  other  than  the  SNOOP  site  must  send  a 
"clear  SNOOP"  message  when  it  has  completed. 

The  results  for  the  canonical  scenarios  are  presented 
for  class  1  and  class  2  transactions.  Figures  3-1'  and  3-5 
show  the  effects  of  varying  the  number  of  locks  at  each 
node  or.  the  USEFULIO  for  each  of  the  four  concurrency  con¬ 
trol  algorithms .  The  horizontal  axis  represents  the 
number  of  locks  in  a  logarithmic  scale.  The  vertical  axis 
is  the  USEFULIO,  or  I/O  resources  used  in  completing  tran¬ 
sactions,  in  1000  time  units  of  the  simulation.  Note  that 
for  six  nodes,  at  most  120,000  time  units  ( NNODES*TMAX )  of 
1/0  resources  are  available.  The  curves  for  the  USEFUL CPU 
measurements  were  very  similar  and  are  not  shown. 

*1.1.  1_.  Class  1_  Transactions 

Figure  3-'*  shows  the  results  for  class  1  transac¬ 
tions.  For  all  four  concurrency  control  algorithms,  the 
maximum  USEFULIO  occurred  with  500  to  1000  granules.  For 
the  primary  site  2  (PS2)  and  the  global  deadlock  detector 
(SNOOP)  models,  the  peak  occurred  at  500  granules.  For 
the  primary  site  1  (PS1)  and  wound-wait  (VJW)  models,  1,000 
granules  were  optimal.  In  either  case,  with  It  of  the 


maximum  tJSEFULIp  was  reached  with  500  or  1000  granules. 

Several  obser vations  about  figure  3-^  should  be 
noted.  First,  the  primary  site  two  model  (PS2)  achieved 
98%  of  the  maximum  USEFULIO  with  100  granules  and  90%  of 
that  maximum  with  as  few  as  50  granules.  Each  of  the 
other  three  models  required  at  least  250  granules  to  reach 
within  10  percent  of  its  respective  maximum.  Thus,  more 
coarse  granularity  was  acceptable  in  the  primary  site  two 
model.  In  that  model,  no  transactions  held  locks  at  ore 
node  while  waiting  for  locks  at  another  node.  In  each  of 
the  other  models  this  condition  was  not  true. 

Second,  the  differences  in  useful  computer  utiliza¬ 
tions  were  very  small  at  the  optimum  granular ities , 
although  the  primary  site  two  model  (PS2)  did  show  a 
slight  advantage.  At  lower  granularities,  the  primary 
site  models  produced  significan tly  more  useful  computer 
utilization  since  transactions  did  not  have  to  be  res¬ 
tarted.  Similarly,  at  lower  granularities,  the  SNOOP 
model  out- per  formed  the  wound-wait  model,  since  it  caused 
even  fewer  transactions  to  be  restarted. 

The  average  response  time  curves  (rot  shown)  for  the 
transactions  in  class  1,  did  not  consistently  favor  any  of 
the  four  algorithms.  However,  at  or  near  the  optimum 
granularity  (1000  leeks  at  each  node),  the  decentralized 
algorithms  had  a  better  average  response  time  than  the 


primary  site  1  model.  This  result  i  r,  expected  ,  sir  c  e 
local  tran sac t iors  can  be  run  without  network  delay. 

Surprisingly,  however,  the  average  respor se  time  was 
even  less  for  the  primary  site  2  model.  In  this  case,  ary 
gains  observed  by  the  local  transactions  in  the  decentral¬ 
ized  models  were  more  than  offset  by  the  extra  delay 
experienced  and  caused  by  distributed  transactions  holding 
locks  at  one  node  while  waiting  for  locks  at  another  rode! 

The  exact  values  of  the  output  parameters  observed 
with  500  locks  at  each  node  for  class  1  transactions  are 
reported  in  Table  3-7. 


Several  observations  should  be  noted.  At  the  primary 
site  2  model,  the  number  of  transactions  completed,  THAN)- 


Table  3-7 

Output  Measurements  for  Class  1  Type  Transactions 


Measuremer  t 

PS  1 

PS2 

ww 

SNOOP 

TRANCOM 

2,688 

3,307 

3,094 

3,029 

AVERRES 

392 

350 

368 

362 

USEFUL 10 

86,056 

87,648 

87,518 

87,556 

USEFULC  PU 

86,065 

86,335 

87 , 522 

87 ,563 

LOCKCPU 

8 '13 

1  ,048 

952 

962 

MESSCPU 

207 

265 

108 

1  03 

TMESS 

9,697 

12,437 

5 , 408 

5,178 

LMESS 

6,799 

8,329 

1  ,545 

1  ,664 

NWOUNDED 

6 

NCONFLICTS 

— 

— 

_ 

68 

NRESTARTED 

- 

— 

1 

0 

DL0STI0 

- 

- 

392 

0.0 

DLOSTCPU 

- 

- 

392 

0.0 
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COM,  was  10%  greater  thar:  with  the  two  distributed  control 
models  and  about  13%  greater  than  with  the  primary  site  1 
model.  However,  the  differences  in  USEFULIO  and  USEFULCPU 
were  not  significantly  different  for  the  four  concurrency 
control  models.  Thus,  the  large  TRANCOM  value  was  due 
primarily  to  the  fact  that  the  PS2  model  favored  smaller 
transactions  and  90%  of  the  workload  included  those  small 
tr an sactior  s . 

With  the  other  models,  larger  distributed  transac¬ 
tions  could  block  both  large  and  small  transactions  at 
several  nodes  while  waiting  for  locks  at  another  node. 
With  the  PS2  model,  however,  the  larger  distributed  tran¬ 
sactions  (which  have  the  greatest  probability  of  con¬ 
flict),  would  release  the  locks  at  lower  numbered  nodes. 

The  LOCKCPU,  MF.SSCPU ,  TMESS  and  LMESS  parameters  were 
also  greater  for  the  primary  site  ?.  model,  since  more 
transactions  had  been  completed. 

As  expected,  message  CPU  overhead  was  lowest  for  the 
decentralized  concurrency  control  algorithms.  Also  note 
that  the  ratio  of  the  total  number  of  lock  messages  sent 
to  the  total  number  of  messages  sent  ( LMESS/TMESS )  is 
about  for  the  Drimary  site  models  versus  .3  for  the  decen¬ 
tralized  control  models.  In  other  words,  two-thirds  of 
the  network  traffic  was  due  to  concurrency  control  in  the 
primary  site  models.  Less  than  one-third  of  the  messages 


147 


in  the  decentralized  models  were  for  concurrency  control. 

The  expected  number  of  messages  shown  in  Table  3-6 
can  be  applied  to  the  number  of  observed  messages  shown  in 
Table  3-7  to  determine  the  exact  number  of  lock  messages 
sent  by  local  transactions.  In  the  primary  site  2  model, 
for  example,  4,108  non-lock  messages  ( TMESS-LMESS )  had 
been  sent.  Since  the  expected  number  of  non-lock  messages 
is  12.4,  311  of  the  3,307  tr an  sac tion s  were  non-local. 
(Note  that  this  number  is  consistent  with  3,307  total 
transactions  and  a  PREDIST  value  of  10%. )  Thus  2,996  tran¬ 
sactions  were  entirely  local  and  yet  were  responsible  for 
7,490  lock  messages. 

Notice  that  a  very  small  number  of  transactions  were 
wounded.  In  the  canonical  scenario  only  10%  of  the  tran¬ 
sactions  were  distrbuted  and  only  conflicts  between  dis¬ 
tributed  transactions  could  cause  wounds.  Furthermore, 
all  locks  are  requested  at  the  beginning  of  a  transaction 
and  were  generally  granted.  Thus,  a  transaction  is  much 
more  likely  to  be  blocked  by  an  older  transaction,  in 
which  case  no  wound  is  sent.  Note  that  many  more  con¬ 
flicts  than  wounds  were  sent.  However,  no  deadlock  was 
detected,  so  no  transactions  were  restarted  in  the  SNOOP 


model . 
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The  number *of  conflicts  in  the  GNOO?  model  was  always 
greater  or  equal  to  the  number  of  transactions  wounded  in 
the  wound-wait  model,  since  all  conflicts  between  distri¬ 
buted  transactions  were  sent  to  the  SNOOP.  However,  the 
number  of  killed  or  restarted  transactions  in  the  SNOOP 
model  was  always  less  than  or  equal  to  the  number  res¬ 
tarted  in  the  wound-wait  model,  since  only  actual 
deadlocks  could  cause  a  restart.  In  fact,  in  the  simula¬ 
tion  results  reported  in  Table  3-7,  no  transactions  were 
restarted  in  the  SNOOP  model. 

ft •  1_ •  2  *  Class  2  Transactions 

The  USEFUL  10  computer  utilization  for  each  of  the 
four  concurrency  control  algorithms  for  class  2  transac¬ 
tions  are  shown  in  Figure  3-5.  Under  the  randomly  placed 
locks  with  only  small  transactions,  the  finest  granular¬ 
ity,  10,000  locks  in  this  case,  was  again  optimal.  With 
this  optimal  granularity,  as  with  class  1  transactions, 
only  slight  differences  in  computer  utilizations  were  due 
to  the  concurrency  control  algorithms. 

However,  the  wound-wait  and  global  deadlock  detector 
algorithms  did  consistently  produce  somewhat  better 
results  than  the  primary  site  algorithms  over  a  wide 
variety  of  granularities.  In  fact,  only  with  fewer  than 
50  locks  at  each  rode,  were  the  primary  site  models 
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No.  of  locks  (log  scale) 

3-5:  Productive  computer  utilization  with 

four  algorithms  urul  Class  J  Transactions. 
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advantageous . 

No  difference  in  computer  utilisation  was  observed 
between  the  two  primary  site  models  once  the  granularity 
became  fine  enough.  This  result  was  true  for  class  2 
transactions,  since  the  probability  of  success  or  a  lock 
request  was  extremely  high.  Thus,  very  few  of  these  tran¬ 
sactions  waited  for  locks  at  one  node,  while  holding  locks 
at  another  node. 

Similarly,  once  the  granularity  was  less  coarse 
(about  50  granules),  little  difference  in  computer  utili¬ 
zation  is  realized  between  the  two  decentralized  algo¬ 
rithms.  This  result  was  also  realized  because  of  the  high 
probability  of  success  on.  a  lock  request. 

Figure  3-6  shows  the  average  response  time  versus  the 
number  of  locks  at  each  node  for  class  2  transactions. 
The  response  time  is  given  in  terms  of  time  units  of  the 
simulation.  In  the  canonical  interpretation  of  the  time 
parameter,  a  response  time  of  61  would  represent  about  1.8 
seconds.  The  dichotomy  between  the  primary  site  algo¬ 
rithms  and  decentr al i zed  algorithms  was  again  realized  in 
these  curves.  As  expected,  the  deceri  tr  al  i  zed  algorithms 
produced  lower  average  response  times,  since  local  tran¬ 
sactions  did  not  need  to  communicate  with  any  other  nodes. 

The  exact  values  of  the  output  measurements  for 
10,000  locks  at  each  node  are  reported  in  Table  3-8  for 


Average  response  time  (time  units  of  simulation) 


IS] 


No.  of  locks  (  log  scale  ) 

Figure  3-6:  Average  Response  time  for  four 

algorithms  and  ('lass  2  Transactions. 
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class  2  tr  an  sac  t  i  or.  s  . 


Note  that  the  network  parameters  observed  the  same 
ratios  of  total  messages  to  lock  messages  as  with  the 
class  1  transactions.  However,  the  differences  in  the 
number  of  lock  messages  between  the  primary  site  models 
and  the  decentralized  models  was  over  40,000  messages  with 
class  2  transactions.  With  that  number  of  messages  it  is 
no  longer  realistic  to  assume  that  the  network  is  'lightly 
loaded'  i.e.,  that  the  message  bandwidth  parameter  is 
infinite.  Restricting  the  message  bandwidth  can  only 
increase  the  differences  between  the  primary  site  control 
and  decentral  ized  control  models  as  will  be  shown  in  sec¬ 
tion.  4.5. 


Table  3-8 

Output  Measurements  for  Class  2  Type  Transactions 


Measurement 

PS1_ 

PS2 

WW 

SNOOP 

TRANCOM 

18,455 

18,461 

19,259 

19,097 

AVKRRES 

64 

64 

61 

62 

USEFUL  10 

93,956 

93,280 

97 , 135 

96,193 

USEFULCPU 

93,996 

93,319 

97 , 145 

92,204 

MFSSCPU 

1,519 

1 ,529 

670 

700 

TMESS 

73,977 

74 , 29? 

33,520 

34,852 

LMF.SS 

51 ,594 

51 , 234 

9,635 

11,093 

NW0UNDED 

NCOMFLI CTS 

0 

- 

- 

5 

N RESTARTED 

- 

- 

0 

0 

DL0STI0 

- 

— 

0 

0 

DLOSTCPiJ 

- 

- 

0 

0 
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The  relatively  small  differerces  ir  average  respcrs^ 
times  between  the  primary  site  and  decentralized  cortrol 
models,  was  at  first  surprising.  However,  most  of  the 
delay  for  the  transactiors  was  due  to  competito  r  for  the 
CPU  and  I/O  resources.  The  network  delay  time  of  2  *  MES- 
RATE  time  units  was  not  a  relevant  factor.  For  example, 
with  ten  transactiors  at  each  node,  a  local  trarsactior 
was  active  at  a  site  with  9  other  transaction s .  For  class 
2  transactions,  the  average  transaction  size  was  5.  Thus 
a  transaction  waited  for  the  I/O  and  CPI)  resources  for 
about  45  time  units  (9  trams  X  5  time  un i t s/ tr nr s)  .  In 
addition,  the  average  transaction  would  spend  5  time  units 
using  the  I/O  and  CPU  resources. 

Thus  55  time  units  of  the  average  response  time  is 
accounted  for  without  considering  lock  conflicts  or  r et- 
work  delays.  If  either  fewer  transactiors  were  running, 
the  transaction  sizes  were  smaller,  or  the  network  were 
slower,  the  2  *  MESRATE  delay  would  further  increase  the 
response  time  difference  between  the  primary  site  ard 
decentral ized  model s. 

The  expected  number  of  messages  shown  in  Table  3-6 
can  also  be  used  in  analyzing  the  number  of  messages  shown 
in  Table  3-8.  In  this  case,  1,859  transactions  were  non¬ 
local  in  the  primary  site  2  model.  Thus,  the  16,602  local 
transactions  accounted  for  41,505  of  the  lock  messages. 
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Note,  however,  that  the  number  of  lock  messages  in 
both  primary  site  models  is  higher  than  the  expected 
number  of  messages  according,  to  Table  3-6.  For  18,461 
trar. sactiors  completed,  46,153  (TRANCOM  *  3(5/6))  lock 
messages  should  have  been  sent.  This  difference  was  due 
to  a  slight  bottleneck  at  the  primary  site.  In  computing 
the  expected  value  it  was  assumed  that  5  out  of  every  6 
transactions  comnleted  would  be  initiated  at  other  sites 
and  thus  require  the  lock  messages.  However,  due  to  the 
bottleneck  at  the  primary  site,  9  out  of  every  10  transac¬ 
tions  were  initiated  at  other  sites. 

In  the  next  sections,  the  effects  of  variation  in  the 
input  parameters  on  the  above  observations  are  reported. 

4.2.  Slavj;  Transactions 

In  a  distributed  database,  not  all  of  the  distributed 
trari sections  require  access  to  data  at  all  of  the  nodes  as 
assumed  in  the  above  results.  In  this  set  of  experiments, 
the  number  of  SLAVES  required  by  each  MASTER  transaction, 
NSLAVE,  was  set  to  1 ,  3  and  5.  With  these  settings  of 
NSLAVES,  a  distributed  transaction  thus  accessed  data  at 
2,  4  and  6  nodes,  respectively.  The  results  of  these 
parameter  settings  for  class  1  and  class  2  type  transac¬ 
tions  for  the  four  concurrency  algorithms  follow. 


Class  1  -Transactions 

The  effects  of  varying  the  number  of  SLAVES  were 
similar  under  any  of  the  four  concurrency  control  nlro- 
rithms.  The  maximum  useful  computer  ut  i  1  i  znt  i  or  again 
occurred  with  500  or  1000  granules  regardless  of  the 
number  of  SLAVES  used  by  a  distributed  transaction.  In 
addition,  all  four  concurrency  control  algorithms  resulted 
in  similar  shifts  in  the  utilization  curves  as  the  number 
of  nodes  per  distributed  transaction  varied.  The  shifts 
are  shown  for  the  SNOOP  algorithm  in  Figure  3-7 . 

As  expected,  as  the  number  of  SLAVES  decreased,  the 
useful  computer  utilization  increased.  Although  the 
optimal  granularity  did  not  change,  the  number  of  granules 
required  to  achieve  utilization  close  to  the  maximum 
decreased  as  the  number  of  SLAVES  decreased.  Tf  each  MAS¬ 
TER  transaction  had  1  SLAVE,  50  locks  resulted  in  9b%  of 
the  computer  utilization  realized  with  500  locks.  With  3 
SLAVES,  91ft  of  the  maximum  utilization  was  realized  with 
50  locks,  while  only  63%  was  realized  if  there  were  6 
SLAVES  for  each  MASTER  tr an  sac ti or  .  Thus,  as  the  number 
of  remote  nodes  decreased,  the  acceptable  grarul nr i tv 
results  resembled  those  observed  ir.  Chapter  ?  for  the  cen¬ 
tralized  database. 
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frrduc l i v o  computer  utilization  wt_h 
different,  r. umber  of  slaves  and  Class  1 
Transactions. 


As  previously  stater),  the  other  th 


i '  t*  < » 


similarly.  In  general,  varying  the  number 
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distributed  transactions  did  rdt  h;ivr*  n  large  i.npni  r 
the  processing  at  the  nodes.  However,  th<*  ut  il  i /at  .)u  o* 
the  network  as  a  function  of  the  number  of  remote  ?  odor; 
does  depend  on  the  concurrency  control  algorithm  weed. 
Table  3-9  shows  the  percentage  of  '‘useful"  messages  (r.  .r- 
lock  related)  for  each  of  the  four  algorithms.  V ;  1  n  'he 
primary  site  models,  the  number  of  lock  messae*  /;  stayed 
constant,  but  the  number  of  non-look  messages  o-i  r 

the  number  of  SLAVES  for  each  MASTER  trar'nrtior:.  dith 
the  decentralized  algorithms,  of  course,  the  ?  »rd'er  (  f 
lock  messages  decreased  as  the  number  of  slaver,  decreased. 


.  2 . 2 .  Class  2  Transactions 

The  number  of  SLAVES  for  a  distributed  transaction 
also  had  little  effect  or'  the  choice  of  concurrent v  cor  - 
trol  algorithm  or  granularity  for  class  ?  Iran  s  v  t  i  re. 
As  in  the  canonical  scenario,  the  finest  grnru!  a  i'v  wi.r 
again  optimal.  In  the  primary  rite  "unj els,  tr»o  r  r'-r 
Table  3-9  Useful  Network  Traffic 


( Nor  -  loc  l< 

Me  s  r>  a  f*  p  r. ) 

of  SLAVF.S 

PS1 

PS? 

WW 

SNOOP 

9% 

1  1% 

71% 

6f)% 

21% 

21  % 

71% 

6f>% 

30% 

33% 

711 

6  H% 

1 

3 

5 
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utilization  and  average  response  time  as  a  function  of  the 
number  of  locks  were  almost  identical  for  one,  three  and 
five  SLAVES  for  each  MASTER  transaction.  For  the  decen¬ 
tralized  concurrency  control  models,  those  three  curves 
were  nearly  identical  with  more  than  50  granules.  With 
fewer  granules,  more  SLAVES  resulted  in  more  transactions 
being  restarted.  In  these  cases,  the  computer  utilization 
was  decreased.  However,  even  with  only  one  slave  per  dis¬ 
tributed  transaction,  performance  of  the  system  with  class 
2  transactions  was  still  extremely  bad  with  coarse  granu¬ 
larity  . 

The  observations  on  the  network  utilization  for  class 
1  transactions  also  hold  for  tr an  sac tion s  in  class  2.  In 
fact,  while  the  number  of  total  and  lock  messages  changed, 
the  percentages  of  useful  messages  were  approximately  the 
same . 

4.3*  Number  of  Network  Nodes 

The  number  of  sites  in  a  distributed  database  can 
vary.  The  simulation,  models  were  run  with  2,  4,  6  and  8 
sites  for  a  variety  of  granularities.  In  order  to  keep 
the  other  factors  constant,  the  canonical  scenarios  were 
changed.  In  all  of  these  experiments,  it  was  assumed  that 
each  distributed  transaction  required  only  ore  slave  run¬ 
ning  at  another  site. 
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4.3*1.  Class  1  Tran sact i or s 

With  mixed  transaction  sizes  and  well-nl;u  oJ  locks, 
there  was  practically  no  difference  between  the  four  co r- 
currency  control  algorithms  as  the  number  of  nodes  ir  the 
network  varied.  Moreover,  neither  the  optimum  gr  an  u  1  ar  i - 
ties  nor  the  shapes  of  the  useful  utilizatior  versus 
granularity  curves  changed  as  the  number  of  nodes  in  the 
network  varied.  The  curves  all  resembled  those  shown  ir 
figure  3-4. 

The  only  changes  in  the  computer  utilizations  were  ir. 
magnitude,  and  those  changes  were  linear  with  respee t  to 
the  number  of  nodes.  Note,  however,  that  it  is  also 
assumed  that  the  network  resources  also  increase  as  the 
number  of  nodes  increase.  Under  the  wound-wait  simula¬ 
tion,  for  example ,  with  2  nodes  the  maximum  useful  utili¬ 
zation  was  30,119  time  units;  with  4  nodes,  59,709  time 
units,  with  6  nodes,  90,47?  time  units,  while  with  8 
nodes,  120,327  time  units  were  used  in  processirg  transac¬ 
tions  . 

The  average  response  time,  or  the  other  hard,  lid  rot 
vary  as  the  number  of  nodes  charged. 
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£.3.?.  Class  2  Transactions 

Linearity  in  computer  utilization  as  a  function  of 
the  number  of  nodes  was  also  observed  for  class  2  type 
transactions.  The  USEFULIO's,  USEFULCPU's  and  average 
response  time  for  the  decentralized  concurr ency  control 
algorithms  were  slightly  better  than  those  measurements 
for  the  primary  site  with  2,  4,  6  or  8  nodes  in  the  com¬ 
puter  network . 

The  cost  of  locking  with  the  many  small  transactions 
and  the  random  placement  of  locks  assumption,  is,  of 
course,  much  greater  than  with  the  class  1  transactions. 
This  cost  also  increased  linearly  with  the  number  of  nodes 
and  was  practically  the  same  for  all  four  algorithms  at 
the  optimum  granularity.  The  lock  costs  for  the  primary 
site  1  model  are  shown  in  Table  3-10: 

The  time  units  per  node  remained  relatively  constant. 
However,  for  the  decentralized  concurrency  control  algo¬ 
rithms,  the  time  units  used  for  locking  were  distributed 
among  all  of  the  nodes.  In  the  primary  site  models  all  of 

Table  3-10:  Time  Units  Spent  Locking 


No .  of  Nodes 

Total  Time  Ur  its 

Time  Units  oer  Node 

2 

"3608  " 

"  ~ 1 704 

4 

676  3 

1691 

6 

10010 

1673 

8 

13300 

1663 

the  time  units  were  used  for  locking  a t  ore  node.  Thus, 
at  the  primary  site  with  S  nodes  in  the  network,  13,300 
out  of  20,000  available  time  units  were  used  for  locking. 

This  increasing  overhead  for  locking  at  ore  rode  has 
two  implications .  First,  transactions  which  use  the  pri¬ 
mary  site  for  data  access  will  receive  much  poorer  service 
than  the  other  nodes.  In  fact,  it  may  be  necessary  to 
reduce  the  transaction  processing  load  at  the  primary  site 
node.  Second,  the  primary  site  can  become  saturated  just 
managing  locks.  With  class  2  transactions  and  the  locking 
overhead  rate  assumed  in  these  experiments,  an  extrapola¬ 
tion  shows  that  the  primary  site  will  saturate  if  there 
are  12  nodes  in  the  network.  Note  that  the  primary  site 
also  has  to  handle  a  disproportior ate  share  of  the  mes¬ 
sages.  The  time  units  used  for  handling  leak  messages 
(MESCPU)  at  the  primary  site  should  al  5>o  be  ii.ludel  i: 
looking  at  primary  site  saturation.  An.  ex  tr  a  no  1  a  t  i  or.  of 
the  total  overhead  (LOCKCPU  +  MESCPU)  shows  that  the  pri¬ 
mary  site  would  saturate  with  only  11  nodes  it  the  r  of- 
wor  k . 

For  the  class  1  transactions,  or  the  other  hsrd,  each 
transaction  required  much  less  locking  overhead  due  to  Uk- 
well-placed  lock  assumption.  Under  those  assu'nnt  i-m  s,  the 
primary  site  would  rot  bottleneck  until  83  rod^s  were  ir 


the  network. 
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4.4,  Percent  of'  Distributed  Transactions 

In  the  previous  simulation  runs,  ten  percent  of  the 
transactions  were  assumed  to  be  distributed,  while  the 
other  transactions  required  processing  at  the  local  nodes. 
In  this  section,  the  effects  of  varying  that  percentage  on 
the  optimum  granularity  and  choice  of  concurrency  control 
algorithms  are  examined.  Experiments  were  run  with  values 
of  0,  10,  25,  50,  75,  and  100  for  the  percentage  of  dis¬ 
tributed  transactions  parameter  (PREDIST).  The  results 
are  presented  for  both  class  1  and  class  2  transactions, 

4.4.  K  C_lass  2  Transactions 

Changes  in  the  percentage  of  distributed  class  1 
transactions  affected  the  optimum  granularities  dif¬ 
ferently  for  the  different  concurrency  control  algorithms. 
In  addition,  as  that  percentage  increased,  the  choice  of  a 
’best’  algorithm  for  class  1  transactions  became  clearer. 

The  results  of  the  simulation.  experiments,  varying 
the  PREDIST  parameter,  are  broken  into  the  following  four 
parts.  First  the  effects  of  the  locking  gr an ul ar i ti e s  on 
the  four  models  are  discussed.  Next  the  four  models  are 
compared,  choosing  the  optimal  granularity  for  each  model 
for  each  setting  of  the  PREDIST  parameter.  Third,  the 
four  models  are  compared  under  alternate  network 
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j:  assumptions.  In  the  final  set  of  experiments,  sox-;*  mes- 

j  sa^es  useful  in  terms  of  crash  recovery  were  a-iced  to  the 

l 

primary  site  model. 

fl.fi_-_l_._1_.  Effects  of  Loo  k  i  r  r  Granularity 

With  any  of  the  four  concurrency  control  algorithms, 
if  0 %  of  the  transactions  were  distributed  (rill  transac¬ 
tions  are  local),  the  maximum  useful  computer  utilization 
occurred  with  from  50  to  5 00  lockable  granules.  These 
results  were  similar  to  the  centralized  database  case  i  r: 
Chapter  2. 

The  optimum  locking  granularity  for  three  of  the  four 
concurrency  algorithms  changed  as  the  percentage  of  dis¬ 
tributed  transactions  increased.  With  the  primary  site  2 
model,  however,  the  maximum  usoful  computer  utiliz.atior 
occurred  at  or  near  500  granules. 

For  example,  in  figure  3-8,  the  shapes  of  the  useful 
1/0  curves  versus  the  number  of  locks  are  very  similar 
when  either  10%  or  75%  of  the  transactions  are  distri¬ 
buted.  For  the  other  three  models,  7f>%  distributed  tran¬ 
saction  curves  were  skewed  to  the  right  whet  compared  t 
the  10%  curves. 

The  difference  between  the  models  is  that  it  the  pri¬ 
mary  site  2  model,  no  transactions  hold  locks  at  ere  nc.de 
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while  waiting  for  locks  at  at  other  rode.  As  the  pore  r*r.  tn^e 
of  distributed  transactions  increased,  there  was  an 
increase  in  the  number  of  trarsactiors  which  hold  leeks  at 
the  other  nodes  in  the  other  models.  Lower  granularity 
increased  the  number  of  incidences  of  this  condition  and 
hence  adversely  affected  the  performance  of  those  algo¬ 
rithms  . 

The  effects  of  varying  the  granularity  and  the  oer- 
centage  of  distributed  transactions  or  the  decentralized 
algorithms  was  even  more  dramatic.  For  these  algorithms, 
a  granularity  from  1000  up  to  5000  locks  at  each  node  was 
required  to  oroduce  the  maximum  computer  utilization  as 
the  percentage  of  distributed  transactions  increased 
beyond  50%. 

The  need  for  finer  granularity  in  these  cases  w as 
caused  by  two  effects.  First,  as  already  menfiorod,  trar¬ 
sactiors  hold  locks  at  one  node  while  waiting  for  looks  at 
a  second  node.  The  second  factor  affecting  the  granular¬ 
ity  in  these  models  was  that  with  coarse  granularity  and  a 
high  percentage  of  distributed  transactions,  mote  transac¬ 


tions  had  to  be  restarted. 
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Model.  Compar i  so  r.  s 

Figure  3-9  shows  the  effects  or  the  useful  I/O  and 
the  average  response  time  of  the  percent  of  distributed 
transactions  for  each  of  the  four  concurrency  control 
algorithms.  (For  each  percentage,  and  for  each  algorithm, 
the  best  useful  I/O  and  average  response  time  regardless 
of  granular ity  was  plotted.) 

The  ’dish1  shaped  curves  for  USEFULIO  were  surpris¬ 
ing.  As  the  percentage  of  distributed  tr  an  sac  tior.s  was 
increased  up  to  50%,  all  four  models  showed  decreases  in 
useful  computer  utilization  due  to  the  additional  overhead 
(message  handling  and  locking)  required  to  run  distributed 
transactions.  However,  as  the  percentage  increased  beyond 
75%,  the  useful  computer  utilization  significantly 
increased  . 

That  increase  was  due  to  two  factors.  First,  the 
number  transactions  running  at  each  node  was  greatly 
increased.  For  example,  when  all  of  the  transactions  were 
distributed,  NMODRS  *  MTRAN  (60  in  the  simulation  runs) 
parts  of  transactions  were  active  at  each  node.  Second, 
the  average  transaction  size  at  each  node  was  smaller  as 
more  and  more  transactions  were  distributed. 

The  simulation  parameters  were  modified  to  keep  the 
number  and  sizes  of  active  transactions  at  each  node  con- 
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stant  as  the  percentage  of  distributed  transactions 
increased.  Only  when  both  parameters  were  held  fixed  did 
the  'dish'  shaped  curves  disaopear.  When  only  ore  of  the 
parameters  (NTRAN  or  AMEAN-BMEAN)  were  held  constant,  hav¬ 
ing  all  transactions  distributed  produced  more  useful  I/O 
(and  CPU)  than  when  only  50%  of  the  transactions  were  dis¬ 
tributed  . 

The  average  response  time  curves  also  demonstrated 
dish  shaped  curves.  In  almost  all  cases,  the  second  pri¬ 
mary  site  model  (PS2),  produced  the  best  average  response 
time  of  the  four  models.  The  holding  of  locks  at  one  node 
while  waiting  for  locks  at  another  was  quite  detrimental 
to  the  throughput  of  the  system  and  occurred  with  increas¬ 
ing  frequency  in  the  other  three  models  as  the  percentage 
of  distributed  transactions  increased. 

When  fewer  than  half  of  the  transactions  were  non¬ 
local  the  SNOOP  and  PS2  models  produced  about  equal  useful 
I/O  and  average  response  times  and  were  slightly  better 
than  the  other  two  models.  However,  when  more  than  half 
of  the  transactions  were  non-local,  the  primary  site  2 
model  produced  significantly  better  results  than  the  other 


three  models. 
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^•^•-1*3.  Limited  Bardwidth 

The  above  observations  change  if  a  lower  network 
bandwidth  was  assumed.  All  four  concurrency  cortrol  sirnu- 
lations  were  rerun,  varying  the  percentage  of  distributed 
transactions  with  a  message  bandwidth  of  6.  This  simu¬ 
lates  an  environment  where  only  six  messages  can  be  active 
in  the  Network  one  at  a  time.  The  tests  included  locking 
granularities  of  500,  1000,  2500  and  5900  locks  at  each 
node.  Additional  values  for  the  PERDIST  parameter  were 
also  tested  and  included  30,  35,  40  and  45  percent.  The 
results  are  shown  in  Figure  3-10. 

V/ith  fewer  than  40?  of  the  transactions  being  non¬ 
local,  the  global  deadlock  detector  algorithm  produced 
more  useful  I/O  utilization  than  the  other  algorithms. 
When  45?  or  more  of  the  transactions  were  distributed,  the 
primary  site  2  model  again  produced  better  results.  In 
these  cases,  the  extra  two  messages  for  locking  were  rot 
that  significant;  a  distributed  transact  1  or  rennired  at 
least  2  *  NSLAVES  messages  anvwav. 

Note  also  that,  the  ’dish1  shape  curves  for  ’ISEFUM^ 
have  practically  disappeared  with  a  limited  bandwidth  net¬ 
work.  In  these  cases  the  extra  network  delay  overhead 
caused  by  an  increased  PRFHTcT  parameter  more  than  offset 
the  increases  in  transaction  parallelism. 


SNOOP 
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4  .  4  .  2  *  ^  .  Altjerrrat^  Primary  Si  to  Model 

Those  differences  between  the  SNOOP  ar.d  P7  0  models 
would  be  even  less,  if  the  primary  site  models  required 
the  ’release  lock’  messar.es  to  he  sent  to  the  SLAVES.  In 
many  database  management  systems,  trarsac tier s  might  be 
backed  out  due  to  system  crashes,  changes  in  a  user’s  mind 
and  a  variety  of  other  reasons.  For  these  reasons,  it  may 
be  desirable  to  have  SLAVES  wait  until  the  transact  lor  has 
completed  at  all  nodes  before  1  committing 1  any  updates. 
In  these  types  of  database  management  systems,  ’all  dor  o’ 
messages  similar  to  the  ’release  locks’  messages  must  be 
sent  to  the  SLAVES  even  with  the  primary  site  cor  cur rer c y 
control  . 

The  primary  site  ?  model  was  modified  to  act.  u.  I'1  . 
send  ’’all  done”  messages  at  the  end  of  each  d  i  str  i  but  : 

transaction.  With  that  modification  and  the  limited 
bandwidth  network,  the  primary  site  2  model  actually  pro¬ 
duced  slightly  less  useful  computer  utilizatior  thar  the 
SNOOP  model,  regardless  of  the  percentage  of  d  i  r  t  r  ;  n -r  **  : 

tr  an  sac  t ions. 

4.4,?.  2  Trarsnct  ions 

With  class  2  tr  an  sac  t  i  or  s  ,  the  finest  granularity  v/as 
optimal,  regardless  of  the  percentage  of  distributed 
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transactions.  Fur thermor e ,  the  performance  of  the  con¬ 
currency  control  algorithms  also  changed  consistently  as 
the  percentage  of  distributed  transactions  increased. 

Figure  3-1 1(a)  shows  the  U.SEFULIO  for  the  four  algo¬ 
rithms  as  that  percentage  increased.  The  utilization  with 
the  decentralized  algorithms  was  affected  very  little  by 
the  increase  in  non-local  transactions.  Again,  a  slight 
increase  in  useful  computer  utilization  was  realized  due 
to  the  increased  distribution  of  transaction  processing. 

In  the  primary  site  algorithms,  on  the  other  hand, 
the  overall  computer  utilization  decreased  as  the  percen¬ 
tage  of  non-local  transactions  increased.  The  decrease 
was  most  dramatic  between  25  and  75  percent. 

The  same  advantage  for  the  decentralized  algorithms 
over  the  primary  site  algorithm  appeared  in  the  average 
response  time,  as  shown  in  figure  3  —  1  1  (t>>  .  For  all  four 
algorithms  the  response  times  increase  as  the  percentage 
of  distributed  transactions  increased.  However,  the 
increase  was  much  less  for  the  decentralized  concurrency 
control  algorithms  than  for  the  primary  site  concurrency 
control  algorithms. 

Two  factors  caused  the  dramatic  difference  between 
the  primary  site  and  decentralized  models  for  class  2 
transactions:  the  transactions  were  all  small  and  the 
primary  site  created  a  bottleneck. 


Average  response  time  UsefuIIO  (xk  time  units) 
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The  transactions  of  class  2  were  all  small  and  the 
results  in  Figure  3-11  were  for  the  finest  granularity. 
Under  those  conditions,  the  probability  of  success  on  a 
lock  request  was  extremely  high,  which  considerably 
reduced  the  advantage  that  the  primary  site  2  model  exhi¬ 
bited  for  class  1  type  transactions. 

The  second  factor  which  affected  the  performance  of 
the  concurrency  control  algorithms  was  the  bottleneck  at 
the  primary  site.  Over  7,000  time  units  out  of  a  possible 
20,000  were  used  for  locking  at  the  primary  site  when  all 
of  the  transactions  were  non-local.  Moreover,  all  tran¬ 
sactions  required  some  database  processing  at  that  primary 
site  and  were  thus  all  delayed  by  the  locking  overhead. 
This  bottleneck  became  increasingly  worse  as  the  percen¬ 
tage  of  distributed  transactions  increased. 

One  solution  to  the  bottleneck  problem  would  be  to 
offload  the  primary  site  concurrency  control  to  a  separate 
processor.  The  primary  site  2  simulation  was  modified  to 
test  this  strategy. 

Two  sets  of  experiments  were  run.  In  the  first  set, 
the  workload  and  network  parameters  remained  the  same  and 
the  concurrency  control  was  off-loaded  to  a  'seventh* 
node.  In  these  experiments,  the  primary  site  model  pro¬ 
duced  USEFULJP  and  average  response  times  very  similar  to 
the  decentralized  control  algorithm  results  shown  in 


figure  3-11-  In  fact,  the  primary  site  models  produced 
slightly  better  results  than  the  decentral  i  zed  models  when 
the  PREDIST  parameter  was  greater  than  50%. 

In  the  second  set  of  experiments,  the  6-node  data¬ 
base,  granules  and  transactions  were  distributed  on  a  5- 
node  network  with  a  sixth  node  being  used  only  for  the 
concurrency  control.  The  results  were  again  similar  to 
those  in  figure  3-11  for  the  decentralized  models.  How¬ 
ever,  in  these  experiments  the  modified  primary  site 
models  produced  slightly  worse  results  than  the  decentral¬ 
ized  models. 

These  two  results  suggest  that  a  proper  database 
design  which  '  lowered  the  load  at  the  primary  site  could 
perform  equally  as  well  as  the  decentralized  algorithms. 

The  PREDIST  simulation  experiments  for  class  tran¬ 
sactions  were  repeated  with  a  limited  bandwidth  la'lwa  k, 
In  these  experiments,  the  primary  site  models  were  heart  If 
more  than  50%  of  the  transactions  were  d  i  :•  tr  i  bid  mi  .  Tr 
those  cases,  the  primary  site  model s  actually  sc: A  fewer 
locking  messages  than  the  decent ral i zed  algorithms. 

jl .  5^ .  N e  t wor  k  P a r  a m *  t  '> r  s 

In  this  section,  the  r  n ;  *  j  l  t  a  of  v  :  r  y  i  rr  f :  v  *  *'  '  t  w  *  *  ■ 

input  parameters  or#  rf  [.  wli-d  .  I  r  4  :  •  v  i  a. .  i  ■  r  ur.  s  :  * 
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MESRATE,  or  the  length  of  time  it  takes  to  send  a  message, 
was  fixed  at  3  simulation  time  units.  The  MESBDWT,  or 
number  of  simultaneously  active  messages,  was  effectively 
set  to  oo ,  by  setting  the  MESBDWT  parameter  to  1000. 

The  data  transfer  parameters,  PRETRAN  and  PREDATT, 
were  also  fixed  in  all  of  the  previous  simulation  experi¬ 
ments.  In  those  experiments  i)05(  (PRETRAN)  of  the  distri¬ 
buted  transactions  sent  25%  (PREDATT)  of  their  entities  to 
other  nodes.  The  DATARATE  parameter  was  set  to  .05,  which 
determined  how  long  it  took  to  send  data  entities  across 
the  network. 

One  other  network  parameter,  the  MESSCPURATE,  while 
not  affecting  the  network  directly,  did  affect  Ue  message 
or  network  overhead  required  at  each  node.  For  all  of  the 
previous  experiments,  a  message  CPU  rate  of  .01  (3 00 
microseconds)  was  assumed. 

Simulations  were  run  with  MESRATES  of  1  (30  msecs),  3 
(90  msecs)  and  10  (300  msecs,  similar  to  the  ARPANET). 
The  simulations  were  also  run  with  MESBDWT  of  100,  50,  10 
and  6.  The  DATARATE  experiments  included,  0.05,  0.1,  0.25 
and  0.5.  The  message  CPU  rate  parameter  was  set  to  .01 
(300  microseconds) ,  0.05  (1.5  msecs),  0.1  (3  msecs)  and 
0.3  (9  msec  s ) . 

Class  ?.  transactions  required  much  greater  use  of  the 
network  resources  than  class  1  transactions.  Thus 


variations  in  the  network  parameters  had  a  much  greater 
effect  on  class  2  transactions. 

—  Class  2  Transactions 

The  significant  effects  of  lowering  the  bandwidth  and 
varying  the  percentage  of  distributed  transactions  have 
already  been  reported  in  section  4.5.  Varying  the  MES- 
RATE,  MESBDWT  and  MESCPURATE  parameters  had  little  effect 
on  the  other  observations  reported. 

The  effects  of  varying  the  message  rate  parameter 
were  slight.  The  results  with,  message  rates  of  1  ar.d  3 
were  almost  identical  for  all  four  concurrency  control 
algorithms.  A  MESRATE  of  10  resulted  in  about  a  5% 
decrease  in  useful  computer  utilization  for  the  primary 
site  models  and  almost  no  change  in  the  useful  utilization 
for  the  distributed  concurrency  control  models. 

MESBDWT  settings  of  100  and  50  produced  useful  com¬ 
puter  utilizations  and  average  response  time  identic; 1  to 
the  infinite  setting  1000  previously  used.  Slight  drops 
in  the  useful  I/O  and  CPU  utilizations  were  realized  with 
message  band  widths  of  10  and  6.  The  drops  with  a  message 
bandwidth  of  10,  however,  were  leas  than  1%  and  not-  con¬ 
sidered  significant. 


A  message  bandwidth  of  6  did  produce  more  noticeable 
reductions  in  the  useful  I/O  and  CPU  utilizations*  The 
drops  in  useful  utilization  were  only  about  2-3%  with  the 
primary  site  and  SNOOP  models.  The  wound-wait  model,  on 
the  other  hand,  realized  a  drop  of  almost  1%.  Although 
the  primary  site  models  sent  more  lock  messages,  they  were 
mainly  sent  one  message  at  a  time.  A  wound  or  kill,  how¬ 
ever,  resulted  in  NSLAVE  messages  being  sent,  or  broadcast 
over  the  network.  These  "bursts"  of  messages  were 
effected  more  by  the  lower  bandwidth  than  the  greater 
number  of  individual  messages  in  the  primary  site  models. 
In  the  SNOOP  model,  on  the  other  hand,  a  conflict  only 
required  1  message.  A  kill  still  required  NSLAVE  mes¬ 
sages,  but  occurred  very  rarely. 

The  change  of  the  DATARATE  parameter  had  little 
effect  on  class  2  transactions.  When  the  DATARATE  was  .5 
and  all  of  a  distribute  transaction’s  entities  were  sent 
across  the  network,  a  decrease  in  the  computer  utilization 
of  only  about  7?  was  realized. 

With  an  extremely  fast  DATARATE  parameter  (.05  as  in 
the  canonical  scenarios),  changes  in  the  number  of  tran¬ 
sactions  which  transferred  data,  or  the  amount  of  data 
they  transferred  produced  curves  almost  identical  to  those 
shown  in  figures  ?-4,  3-5  end  3-0,  sr.d  are  not  repeated 
here.  A  slight  drop  in  useful  I/O  and  CPU  time  was 
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observed  as  the  amount  of  data  transferred  increased  for 
both  classes  of  transactions  and  for  each  of  the  con¬ 
currency  control  algorithms.  However,  even  if  all  of  the 
distributed  transactions  transfer  all  of  their  data,  the 
decrease  was  less  than 

Note  that  these  results  do  not  imply  that  data 
transferred  is  not  an  important  parameter  in  a  distributed 
database.  In  the  models  considered  here,  data  transfer 
resulted  in  a  waiting  time  for  that  transfer  to  complete. 
Under  these  assumptions,  no  additional  I/O  or  CPU 
resources  were  used  in  transferring  data;  it  was  assumed 
that  use  of  these  resources  is  already  included  in  tran¬ 
saction  processing.  Furthermore,  with  the  fast  DATARATE 
assumed,  even  a  transaction  accessing  500  entities  would 
wait  on  the  transaction  wait  queue  for  only  2 5  time  units. 

When  the  DATARATE  was  increased  from  .05  to  .5,  and 
the  PRETRAN  and  PREDATT  parameters  were  varied,  a  larger 
drop  in  useful  CPU  and  I/O  utilization  was  observed.  At 
the  optimum  granularity,  a  drop  of  almost  7  %  in  computer 
utilization  was  realized.  In  those  cases ,  the  larger 
transactions  might  wait  on  the  CPU  queues  for  ?r,0  time 
units,  a  significant  portion  of  their  lifetimes. 

Changes  in  the  KP/n  CRATE  parameter  had  the  greatest, 
effect  on  the  useful  computer  ut.  i  1  i  cat  i .  r  output  pai  amc- 
tcr  5 .  In  the  primary  rile  models,  a  -V  err  are  of  nlr.o  M. 


was  realized  when  the  message  rate  was  increased  to  .3 
(almost  9  msecs).  With  that  same  message  rate,  the  useful 
computer  utilization  only  dropped  by  about  4 %  in  the 
decentralized  models. 

In  class  1  transactions,  the  critical  resources  ar 
the  I/O  and  CPU  resources  at  the  nodes  and  not  the  network 
resources.  Thus  the  heavy  message  traffic  of  the  primary 
site  models  is  impacted  much  more  by  the  message  CPU  rate 
than  the  other  network  parameters. 

H‘5-2.  Class  2  Transactions 

The  MESRATE,  MESC PURATE ,  MESBDWT,  and  DATARATE  param¬ 
eters  were  also  varied  for  class  2  transactions .  Changes 
in  the  first  three  parameters  affected  the  performance  of 
all  four  concurrency  control  algorithms.  The  DATARATE 
parameter  had  practically  no  effect  on  the  processing  of 
class  2  transactions. 

The  USEFULIC  and  the  average  response  time  (in 
parenthesis)  is  given  in  Table  3-11  for  each  of  the  four 
concurrency  control  algorithms.  In  the  first  set,  the 
MESRATE  parameter  was  varied  while  the  KESCPURATE  and 
MESBDWT  were  fixed  at  .01  and  1000  respectively.  As  the 
message  rate  increases,  the  gap  between  the  primary  site 
and  decentralized  control  models  widened. 
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Table  3-11:  Effects  of  Network  Parameter s 


MESRATE 

1 

PS  1 

94994(63) 

PS2 

94720(63) 

WW 

96839(6  1  ) 

SNOOP 

97037(62) 

3 

93996(64 ) 

93319(64 ) 

971  34  (6  1  ) 

96204(6 2) 

10 

87998(67) 

88078(67 ) 

96037(63) 

96875(62  ) 

MESCPURATE 
.01  93996(64 ) 

93319(64) 

97145(65) 

96204 (62) 

.05 

88953(67) 

88767(68) 

95048(63) 

94710(64  ) 

.  1 

83273(72  ) 

83086(73  ) 

92394(65) 

91860(65 ) 

.3 

58676(102) 

58372 (102) 

83313(72) 

82690(73) 

MESOULP 

1000-50 

93996(64 ) 

93319(64 ) 

97145(6  1  ) 

96204(62) 

10 

82804(72) 

83234(72) 

96827(6?) 

96979(62) 

6 

55200(108) 

55692(108) 

95948(63) 

96242(62) 

A  more  dramatic  change  occurred  when  the  message  CPU 
rate  was  varied.  During  these  experiments,  the  MESRATE 
and  MESBDWT  were  fixed  at  3  and  1000  respectively.  With  a 
3  millisecond  cost  (MESCPURATE  =  .1)  for  sending  a  mes¬ 
sage,  the  primary  site  models  produced  only  89%  of  the 
useful  computer  utilization  that  was  realized  with  the 
decentralized  concurrency  control  algorithms.  With  a  9 
msec  message  rate  (MESCPURATE  =  .3)  this  percentage  drops 
to  72%. 


Similarly,  a  dramatic  change  in  USF'F'JLIO  and  response 
time  for  the  primary  site  models  was  realized  as  the  mes¬ 
sage  bandwidth  was  restricted.  Eor  these  experiments,  the 
message  rate  and  message  CPU  rate  parameters  were  fixed  at 
3  and  .01  respectively.  hate  that  while  the  performance 
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of  the  primary  site  models  was  heavily  affected  by  the 
restricted  bandwidth,  the  decentralized  models  were  hardly 
affected  at  all.  This  result  is  due  to  the  fact  that  with 
the  primary  site  models,  almost  40,000  more  messages  were 
sent  than  with  the  decentralized  algorithms. 

Variations  in  the  DATARATE,  PRETRAN  and  PREDATT 
parameters  had  little  or  no  effect  on  the  performance  of 
the  four  concurrency  control  algorithms.  Class  2  transac¬ 
tions  were  all  small.  Thus  any  wait  on  the  data  transmis¬ 
sion  queue  was  also  small  even  if  all  of  the  distributed 
transactions  transferred  all  of  their  data. 

As  expected,  the  performance  of  a  primary  site  con¬ 
currency  control  algorithm  deteriorated  as  restrictions 
were  placed  on  the  network.  The  effect  of  the  restric¬ 
tions  on  the  wound-wait  and  SNOOP  algorithms  was  much 
smaller . 

4.6.  Canonical  Scenario  Revisited 


In  section  4.1,  the  effects  of  the  different  con¬ 
currency  control  algorithms  on  computer  utilization  and 
average  response  times  with  two  different  classes  of  tran¬ 
sactions  were  presented.  In  those  experiments  a  very 
fast,  low  overhead  and  high  bandwidth  network  was  assumed. 
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Subsets  of  those  cases  were  rerun  under  alternate 
network  assumptions.  For  the  results  presented  in  Figure 
3-12,  the  MESRATE  was  assumed  to  be  10  simulation  time 
units  or  about  .3  seconds.  The  MESBPWT  parameter  was  set 
to  6,  while  the  MESCPURATE  was  set  to  .1,  simulating  a 
cost  of  about  3  msecs  to  handle  a  message  at  a  node. 
These  settings  roughly  resemble  the  ARPANET  parameters. 
Note  that  the  simulations  were  not  run  for  all  of  the 
granularities. 

In  section  4 .  1  for  class  1  transactions  with  finer 
gr an ul ar i t i e s ,  no  one  concurrency  control  algorithm  seemed 
dominant.  Figure  3-1?  shows,  on  the  other  hand,  that  the 
decentralized  algorithms,  the  wound-wait  or  SNOOP,  produce 
significantly  better  machine  utilization  than  the  primary 
site  models.  The  drop  of  about  9%  realized  with  the  pri¬ 
mary  site  models,  when  compared  to  the  decentralized 
models,  is  consistent  with  the  drop  observed  in  section 
*4 . 6 ,  when  only  one  of  the  network  par  a  me  tors  was  varied. 

The  advantage  of  the  decentralized  algorithms  for 
class  1  type  transactions  shown  in  section  U.1  became  even 
more  apparent  when  a  slower  network  was  assumed.  Note, 
however,  that  under  the  given  network  parameter  the  useful 
computer  utilizations  for  even  the  decentralized  algo¬ 
rithms  were  much  lower  than  with  the  original  ret  work 
parameters.  Thus,  regardless  of  the  concurrency  control 
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algorithm,  a  ’distributed  database  where  nil  transactions 
are  very  small  is  perhaps  not  suitable  for  a  slow  computer 
network  . 


5.  CONCLUSIONS 

As  with  the  centralized  database  concurrency  control, 
the  algorithms  and  parameters  of  the  concurrency  control 
for  a  distributed  database  are  also  application  and  system 
dependent.  In  this  section  the  major  conclusions  on  the 
locking  granularity,  the  algorithms  for  class  1  and  class 
2  type  transactions  are  reviewed. 

5._1*  Locking  Granularity 

In  general,  a  finer  granularity  is  required  for  lock¬ 
ing  in  a  distributed  database  than  in  a  centralized  data¬ 
base.  However,  if  the  locks  are  well-placed  with  respect 
to  the  accessing  transac tions ,  the  finest  granularity  is 
still  not  worth  the  additional  concurrency  produced. 

The  need  for  finer  granularity  in  a  distributed  data¬ 
base  was  caused  by  one  major  factor:  transactions  held 
locks  at  one  node  while  waiting  for  locks  at  another  node. 
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When  that  condition  was  avoided  with  the  PS2  model,  much 
coarser  granularity  was  acceptable. 

Even  that  model,  however,  required  slightly  less 
coarse  granularity  than  was  required  for  a  centralized 
database  under  the  same  assumptions.  In  the  centralized 
database,  10  to  100  granules  produced  the  maximum  useful 
computer  utilization  under  the  well-placed  lock  assump¬ 
tions.  In  the  PS2  distributed  database,  100  to  1000 
granules  are  required.  In  the  PS2  model  and  very  coarse 
granularity,  many  distributed  transactions  have  to  release 
and  rerequest  locks  at  a  low  number  nodes.  The  additional 
locking  overhead  makes  coarse  granularity  unacceptable. 


5.2.  Class  1  Transactions 


If  the  number  c*f  distributed  transactions  is  low 
(£10%)  and  the  network  is  considered  lightly  loaded,  the 
performance  of  all  four  concurrency  control  algorithms  was 
very  similar  for  class  1  transactions. 

As  the  percentage  of  distributed  transactions 
increase,  the  primary  site  2  model  produces  better  com¬ 
puter  utilization  and  average  response  times  than  either 
of  the  decentralized  models.  In  these  cases,  the  extra 
two  messages  required  in  the  primary  site  model  represent 
a  lower  percentage  of  overhead  since  the  transactions  will 
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be  sending  at  least  2  *  NSLAVE  messages  anyway.  Moreover, 
this  overhead  is  more  than  offset  by  the  ability  to  avoid 
inactive  nodes. 

When  the  bandwidth  of  the  network  is  lowered  and  the 
number  of  distributed  transactions  is  low,  however,  the 
decentralized  concurrency  control  models  produce  better 
computer  utilization  and  response  time  than  the  primary 
site  models.  In  these  cases,  the  primary  site  lock  mes¬ 
sage  overhead  interferes  with  the  normal  transaction  pro¬ 
cessing  . 

The  above  two  conclusions  come  into  conflict  as  the 
percentage  of  distributed  transactions  increases  and  a  low 
bandwidth  network  is  assumed.  The  simulation  results 
indicate  that  with  a  low  bandwidth  network,  the  SNOOP  dis¬ 
tributed  concurrency  control  algorithm  is  best  when  less 
than  45?  of  the  transactions  are  distributed.  When  more 
than  45?  of  the  transactions  are  distributed,  the  primary 
site  2  model  is  preferred. 

When  the  percentage  of  distributed  transactions  is 
less  than  10?,  the  SNOOP  and  wound-wait  algorithms  perform 
equally  well.  However,  as  that  percentage  increases,  the 
SNOOP  model  results  in  better  performance  than  the  wound- 
wait  model.  As  expected  in  these  cases,  the  percentage  of 
conflicts  increases  and  has  a  more  adverse  effect  on  the 


wound-wait  algorithm. 
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5.3*  Class  2  Transactions 

Under  the  class  2  transaction  assumption,  all  of  the 
transactions  are  small  and  randomly  access  entities  in  the 
database.  In  these  cases,  the  decentralized  concurrency 
control  models  consistently  produce  better  response  times 
and  useful  I/O  and  CPU  utilization  than  the  primary  site 
models.  With  extremely  small  transactions,  the  extra  mes¬ 
sages  in  the  primary  site  models  represent  a  significant 
delay  factor.  Furthermore,  the  small  transactions  make 
the  probability  of  conflict  and  restart  very  low  with  the 
dectralized  concurrency  control  algorithms. 

Also,  with  only  small  transactions  and  random  lock 
placement  assumptions,  the  locking  overhead  is  a  signifi¬ 
cant  factor.  When  all  of  this  overhead  is  concentrated  at 
one  site,  that  site  can  bottleneck  as  either  the  number  of 
sites  in  the  network  or  the  percentage  of  distributed 
transactions  increase. 

The  above  observations  for  class  2  transactions  hold 
even  under  optimistic  network  conditions.  As  the  network 
parameters  become  restrictive,  the  advantages  of  the 
decentralized  concurrency  control  become  even  more  evi¬ 
dent. 

The  wound-wait  and  SNOOP  concurrency  control  models 
produced  extremely  similar  results  for  class  2  transac- 
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tions.  This  similarity  was  due  to  two  factors.  First, 
the  small  transactions  are  involved  in  very  few  conflicts 
and  thus  the  probability  of  a  transaction  blocking  and 
being  blocked  by  an  older  distributed  transaction  is 
extremely  small.  The  second  factor  is  that  a  transaction 
is  much  more  likely  to  be  blocked  by  an  older  transaction 
(in  which  case,  no  wound  or  kill  takes  place)  since  the 
individual  sites  operate  with  a  preclaim  locking  strategy. 


CHAPTER  4 


CONCLUSIONS 


The  major  goal  of  this  thesis  was  to  examine  the 
effects  of  concurrency  control  on  the  performances  of 
database  management  systems.  The  effects  of  concurrency 
control  on  performance  are  dependent  on  two  conflicting 
factors.  On  the  other  hand,  the  database  system  perfor¬ 
mance  can  be  enhanced  by  allowing  concurrent  users  simul¬ 
taneous  access  to  the  database.  Both  the  useful  computer 
utilization  and  the  average  response  time  can  be  improved 
by  supporting  a  multiple  user  environment. 

On  the  other  hand,  the  database  system  performance 
might  be  degraded  due  to  extensive  concurrency  control 
overhead.  The  concurrency  control  overhead  is  due  to  the 
computer  resources  utilized  in  some  type  of  "locking". 
The  "locking"  is  used  to  prevent  one  user  of  the  database 
from  interfering  with  the  processing  of  another  user. 

In  the  first  section  of  this  chapter,  the  major  con¬ 
clusions  from  Chapters  2  and  3  are  reviewed.  In  the  next 
section  the  applications  of  these  conclusions  to  other 
concurrency  control  implementations  are  projected  and 
several  areas  of  further  research  are  suggested. 
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SUMMARY  OF  PREVIOUS  CONCLUSIONS 

Simulation  models  were  used  to  study  the  performance 
effects  of  concurrency  control  in  both  centralized  and 
distributed  databases. 


1.1.  CENTRALIZED  DATABASES 


In  a  centralized  database,  all  database  activity, 
including  concurrency  control,  are  processed  on  a  single 
computer  system.  A  simulation  model  was  used  to  determine 
the  optimum  granularity  for  locking,  the  effects  of  a 
variety  of  workload  and  system  characteristics,  the 
effects  of  a  lock  hierarchy,  and  the  effects  of  a  '’pre- 
claim"  versus  a  "claim  as  needed"  locking  strategy. 

The  overall  conclusions  on  locking  granularity  are 
application  dependent  as  shown  in  Table  4-1. 


Table  4-1  Locking,  Granularity 

small  large  mixed  sized 

Transactions  Transactions  Transactions 

Wei 1-pl aced 

Random 

pi acement 


Fine  gran 


Coarse  gran 


Lock  Hiernrc 
with  Fine  g  r 
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In  many  cases  coarse  granularity,  such  as  file  or 
relation  locking,  is  preferred.  However,  if  random  lock 
placement  is  assumed  and  all  of  the  transactions  are 
small,  the  coarse  granularity  is  unacceptable  and  fine 
granularity  locking  must  be  implemented. 

If  random  lock  placement  is  assumed  and  a  variety  of 
different  sized  transactions  are  present  in  the  workload, 
a  lock  hierarchy  should  be  used.  In  such  a  hierarchy, 
some  large  transactions  can  lock  large  granules,  while 
other  small  transactions  lock  much  finer  granules.  If  a 
transaction  were  to  set  more  than  \%  of  the  smaller  locks 
under  any  one  large  lock,  it  would  be  more  efficient  for 
that  transaction  to  simply  set  the  one  large  lock. 

In  a  preclaim  locking  strategy,  a  transaction 
acquires  all  of  its  locks  at  the  beginning  of  the  transac¬ 
tion.  In  a  claim  as  needed  locking  strategy,  the  locks 
are  acquired  as  the  respective  parts  of  the  database  need 
to  be  accessed.  With  a  fev;  exceptiors,  the  preclaim  stra¬ 
tegy  produced  better  machine  utilization  than  the  claim  as 
needed  model.  However,  the  above  conclusions  on  locking 
granularity  and  a  lock  hierarchy  hold,  regardless  of 
whether  a  proclaim  or  claim  as  needed  strategy  is  used. 


1  .  p  .  D i s t r  i  touted  Fa t a base s 


In  a  d i s t r i b u t e d  database,  the  database  activity, 
including  the  concurrency  control,  are  processed  on 
several  computer  systems  connected  by  a  network.  Four 
concurrency  control  algorithms  were  simulated  in  order  to 
study  their  performance  effects  under  a  variety  of  work¬ 
load  and  network  conditions. 

Two  of  the  algorithms  simulated  involved  a  central¬ 
ized  concurrency  control  where  locking  for  the  entire 
database  was  controlled  at  one  primary  site  in  the  net¬ 
work.  In  the  "primary  site  1”  model,  transactions  acquire 
the  locks  needed  at  each  node  or  site  in  some  fixed  order. 
If  the  locks  for  one  node  are  denied,  the  "blocked"  tran¬ 
saction  waits  for  those  locks  while  holding  locks  on  lower 
ordered  nodes. 

In  the  alternate  centralized  control  model,  the  "pri¬ 
mary  site  2"  model,  the  locks  needed  at  each  node  are 
again  acquired  in  some  fixed  order.  However,  in  thin 
case,  if  the  locks  for  one  node  are  denied,  the  ’ blocked* 
transaction  releases  all  currently  held  locks  while  writ¬ 
ing  for  access  to  the  locked  granules. 

The  other  two  algorithms  simulated  involved  a  decen¬ 
tralized  concurrency  control  where  locking  for  the  portion 
of  the  database  at  each  node  was  controlled  at  that  node. 
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In  the  "wound-wait"  model,  deadlock  is  prevented  by 
"wounding"  any  "young"  transaction  that  dares  to  block  an 
"older"  transaction.  The  wound  is  transferred  to  all 
sites  where  the  wounded  transaction  is  active.  If  a 
wounded  transaction  is  blocked  at  any  site  by  an  "older 
transaction,  the  wounded  transaction  releases  its  locks  at 
each  site  and  is  then  restarted. 

In  the  other  decentralized  control  algorithm, 
deadlocks  are  resolved  by  a  global  deadlock  detector,  or 
"SNOOP".  If  a  deadlock  exists,  a  transaction  is  picked 
which  also  releases  its  locks  at  each  site  and  is  then 
restarted  . 

Which  model  is  best  in  terms  of  its  effect  on  the 
distributed  database  system  performance  is  also  applica¬ 
tion  dependent  as  shown  in  Table  4-2.  Class  1  transac¬ 
tions  refer  to  a  workload  environment  where  the  locks  are 
assumed  to  be  well-placed  with  respect  to  the  accessing 
transactions  and  that  those  transaction^  are  of  mixed 
sizes.  Class  2  transactions  refer  to  workloads  where  all 
of  the  tr an  sac tions  are  small  and  random  placement  of 
locks  is  assumed  . 

In  some  cases,  it  appears  that  the  concurrency  con¬ 
trol  mechanism  is  not  a  significant  factor  in  the  database 
system  performance.  For  class  2  transactions,  additional 


Table  *J-2:  Concurrency  Control  Models 

Cl  ass  1  Class? 

Tr an  sac  t i on  s  Transactions 

Fast  Net.  Primary  Site  or  Primary  Site  or 

Most  trans.  Decentralized  Decentralized 

local 

Slow  Net.  SNOOP  Decentralized 

Most  trans. 

local 

Fast  Net.  Primary  Site  2  Decentralized 

Most  trans. 

non-local 

Slow  Net.  Primary  Site  2  Primary  Site 

Most  trans. 

non-local 

simulation  runs  showed  that  the  preference  for  decentral¬ 
ized  concurrency  control  could  be  offset  by  reducing  the 
database  load  at  the  primary  site.  Thus  in  these  cases, 
the  choice  of  concurrency  control  algorithm  may  again  not 
be  significant. 

For  class  1  transactions,  when  most  of  the  transac¬ 
tions  only  required  local  processing  and  a  slower,  lower 
bandwidth  network  is  assumed,  the  DN20F  algorithm  \ r  pre¬ 
ferred.  In  this  case,  the  SNOOP  model  was  favored  l  t  • .  4,u:  ■ 
of  the  lower  number  of  messages  required. 

Also  for  class  1  l  ?  ansae  lions  ,  if  most  of  t*.e  '  r,iti- 
sactians  are  non-local  or  distributed ,  the  primary  site  ; 
model  is  preferred.  The  advantage  of  the  primary  site 
model  is  that  onTy  in  that  model  does  a  t r  an  r  .n*  t  i .  .n 
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release  locks  at  all  other  nodes  while  waiting  for  locks 
at  one  node.  In  the  other  three  models,  it  is  possible 
for  a  transaction  to  hold  locks  at  one  node  while  waiting 
for  locks  at  another  node. 

Another  factor  which  favors  the  primary  site  2  model 
over  the  decentralized  models  when  most  transactions  are 
distributed,  is  that  in  those  cases,  the  primary  site 
model  no  longer  produces  heavier  message  traffic. 

The  distributed  database  simulations  indicated  that 
some  of  the  coarse  granularity  conclusions  for  the  cen¬ 
tralized  database  do  not  hold  for  the  distributed  data¬ 
base.  However,  under  the  well-placed  lock  assumptions, 
the  finest  granularity  is  still  worse  than  a  medium  granu¬ 
larity  concurrency  control. 

Z-  FUTURE  DIRECTIONS 

The  results  of  the  simulation  studies  suggest  several 
areas  for  future  study.  Two  such  areas  would  be  to  extend 
the  lock  hierarchy  and  the  claim  as  needed  locking  models 
to  a  distributed  database.  Another  study  would  be  to 
investigate  the  multiple  copy  problem  in  the  distributed 
database  model.  The  remits  of  the  simulations  in  this 
study  do,  however,  provide  some  insights  in  each  of  those- 
areas. 
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For  the  centralized  database,  the  conclusion  was 
reached  that  if  the  locks  are  well -placed,  coarse  granu¬ 
larity  is  preferred  and  a  lock  hierarchy  is  thus  not  bene¬ 
ficial.  In  those  cases,  it  was  mere  efficient  to  just  use- 
one  level  of  coarse  locking  (10  to  100  locks).  In  the 
distributed  database  cases,  finer  granularity  (500  to  1000 
locks)  is  required  even  if  well-placed  locks  are  assumed. 
A  lock  hierarchy  in  that  granularity  range  was  beneficial. 
Thus  a  lock  hierarchy  at  each  node  for  a  distributed  data¬ 
base  might  be  more  useful  than  in  a  centralized  database. 
This  projection  could  be  verified  by  simple  extensions  to 
the  distributed  database  simulations  similar  to  the  exten¬ 
sion  in  chapter  2. 

A  claim  as  needed  locking  strategy  may  be  required  if 
the  entities  to  be  accessed,  ^^nd  hence  the  granules  to  be 
locked,  are  dependent  upon  the  values  of  entities  previ¬ 
ously  accessed.  With  a  claim  as  needed  locking  strategy 
in  a  distributed  database,  the  primary  site  models  might 
require  two  messages  for  every  lock  set.  In  addition, 
with  claim  as  needed  locking,  the  primary  site  models 
would  also  have  to  prevent  or  detect  dead-'  'ek  ami  thus 
lose  one  of  their  advantages  over  the  decentralized 
models.  Therefore,  for  claim  as  needed  locking,  t ho  pri¬ 
mary  site  model s  would  probably  not  be  accept  a!  ^  . 
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The  comparison  of  the  two  decentralized  concurrency 
control  algorithms  might  be  affected  by  a  claim  as  needed 
locking  strategy.  With  the  preclaim  locking  strategy  and 
the  wound-wait  model,  relatively  few  transactions  were 
wounded  since  there  was  a  high  probability  that  a  blocking 
transaction  was  older  than  the  blocked  transaction.  With 
a  claim  as  needed  locking  strategy,  however,  a  transaction 
would  request  locks  at  several  different  instances  during 
its  lifetime.  Thus,  the  probability  of  being  blocked  by  a 
younger  transaction  would  increase.  Consequently,  the 
global  deadlock  detecter  or  SNOOP  algorithm  would  probably 
be  better  than  the  wound-wait  algorithm  in  a  claim  as 
needed  locking  environment.  Simple  simulation  extensions 
could  also  be  used  to  test  that  hypothesis. 

The  multiple  copy  concurrency  problem  was  discussed 
in  Chapter  1.  In  a  distributed  database,  it  is  sometimes 
advantageous  to  replicate  parts  of  the  database  at  several 
of  the  nodes  in  the  network.  The  multiple  copy  con¬ 
currency  problem  is  to  ensure  that  the  replicated  copies 
are  kept  mutually  consistent  or  identical  during  simul¬ 
taneous  user  updates. 

The  four  distributed  database  concurrency  control 
simulations  could  be  applied  to  the  multiple  copy  problem 
as  follows.  Assume  that  the  entire  database  is  replicated 
at  each  node.  Gone  transactions  are  'read-only'  transac- 


tions  and  just  need  to  access  the  data  at  one  node.  These 
transactions  can  be  considered  the  local  transactions  in 
the  sirnul  ations .  The  •write1  transaction,  on  the  other 
hand,  must  cause  activity  at  each  node  and  thus  may  be 
considered  the  distributed  transactions. 

In  this  in  ter pretat ion ,  the  PREDIST  parameter  would 
represent  the  percentage  of  update  trar.sac tions .  Under 
the  above  in  ter pretat ion ,  the  conclusion  summarized  in 
Table  4-2  can  be  applied  to  the  multiple  copy  problem.  If 
the  database  is  dominated  by  updates  (i.e.  most  transac¬ 
tions  non-local)  and  the  updates  are  relatively  large  and 
sequential  in  nature  (i.e.  Class  1  transactions),  a  pri¬ 
mary  site  concurrency  control  is  suggested.  Thus  all 
transactions  would  first  acquire  locks  at  a  ’primary  copy’ 
of  the  data. 

However,  if  all  of  the  updates  are  small  and  random 
in  nature  (i.e.  Class  2  transactions)  or  most  of  the 
transactions  are  1  read-only’  with  respect  to  this  database 
portion  (i.e,  local  transactions)  then  a  decentra] i zed 
concurrency  control  is  suggested  (or  is  at  least  accept¬ 
able).  In  a  decentralized  concurrency  control,  the 
updates  would  request  locks  at  each  rede  and  proceed  with 
the  updates.  However,  the  updates  would  have  to  to 
prepared  to  be  rolled  back  due  to  conflicts  with  other 


updates . 
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However,  the  above  analysis  is  an  over  simplification 
of  the  multiple  copy  problem  in  a  distributed  database. 
One  over  simplification  is  that  other  concurrency  control 
solutions  exist  to  the  multiple  copy  problems  which  are 
not  directly  extendible  to  the  internal  database  con¬ 
sistency  problems.  These  algorithms  must  also  be  compared 
v/ith  the  simulated  algorithms. 

More  importantly,  the  above  analysis  assumes  a  fixed 
distribution  of  the  copies  in  the  distributed  database. 
In  other  words,  the  database  is  fully  replicated  and  then 
the  number  of  updates  and  the  network  parameters  are 
varied.  But  the  optimum  replication  of  the  data  actually 
depends  on  the  proportion  of  updates  and  the  network 
parameters.  In  fact  the  optimum  replication  of  the  data 
may  be  influenced  by  the  multiple  copy  concurrency  con¬ 
trol. 

These  analysis  deficiencies  cannot  be  over  come  by 
straightforward  extensions  to  the  existing  simulation 
models.  Instead  a  more  complete  model  should  be  developed 
to  jointly  study  the  database  consistency  and  multiple 
copy  problems. 

In  summary,  this  dissertation  provides  insights  into 
the  effects  of  concurrency  control  on  database  system  per¬ 
formance  under  a  wide  variety  of  conditions.  The  results 
of  the  dissert. .lion  can  be  used  to  guide  concurrency 
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